Archivo del Autor: alfonso

Forzando los merge commits

Una de las preguntas más habituales que se hacen en los cursos de git que imparto regularmente, y que también se me ha planteado en algunas de las reuniones de desarrolladores en las que participo es la siguiente: ¿Cómo evito un fast-forward para dejar constancia en el repositorio de dónde empieza y termina una rama?

Forzar merge commits

Lo más claro, como siempre, es verlo con un ejemplo. Imaginad que llegáis por la mañana al trabajo y empezáis como siempre a picar código como locos en la rama devel. De repente surge la necesidad de atender un bug. Siguiendo las buenas prácticas, lo que haremos será crear una rama HotFix, arreglar el problema haciendo cuantos commits necesitemos a esa rama y finalmente hacer un merge a la rama que corresponda cuando terminemos de corregir el bug.

En la siguiente captura se muestra el estado del repositorio justo después de haber hecho el último commit a la rama hotfix_14523 que arregla el problema en cuestión:

Estado del repositorio al terminar el hotfix 15423

Si en este momento se hace un merge de la rama hotfix_15423 a la rama devel, se hará un fast-forward:

$ git checkout devel
$ git merge hotfix_15423
Updating 2d1d1c4..2b9d126
Fast-forward
Gemfile | 2 ++
app/views/home/index.html.erb | 1 +
2 files changed, 3 insertions(+)

Así queda el grafo después de hacer el merge:Estado del repositorio tras hacer un merge con fast-forward de la rama hotfix_15423

Como vemos, mirando la historia del repositorio, no queda constancia de cuándo se empezó el desarrollo de la rama hotfix_15423 y cuándo se incorporó a la rama devel. Una solución podría ser etiquetar los commits correspondientes, como se muestra en la siguiente captura:Usando etiquetas para indicar el inicio y final de una rama

Esta solución es válida cuando tenemos pocas ramas. Si tenemos muchas ramas de las que queramos saber su inicio y final, podemos acabar con un número de etiquetas difícil de gestionar.

Forzar un merge commit

Volvamos a la situación inicial:

$ git reset --hard 2d1d1c4
HEAD is now at 2d1d1c4 Update README.rdoc

Estado del repositorio al terminar el hotfix 15423

En esta situación, volvemos a ejecutar el merge de la siguiente forma:

$ git merge --no-ff hotfix_15423 -m'Incorporando rama hotfix_15423'
Merge made by the 'recursive' strategy.
 Gemfile | 2 ++
 app/views/home/index.html.erb | 1 +
 2 files changed, 3 insertions(+)

Después de ejecutar el comando, este es el estado del repositorio:

Incoporando hotfix15423 en devel con la opción --no-ff

Haciéndolo de esta forma, en lugar de hacerse un fast-forward, vemos que se crea un merge-commit, lo que resulta en una bifurcación que indica claramente el fin y el inicio de la rama hotfix_15423.

Si sois de los que os gusta ver claramente dónde empiezan y terminan vuestras ramas, este pequeño truco es resultará de utilidad.

¿Qué es un pull request?

En esta entrada, la tercera de una serie de tres, explicamos qué es un pull request y cómo funciona en github.

Recordamos brevemente qué es lo que nuestros usuarios aalbagarcia y aprendegit-user1 hicieron en las dos entradas anteriores:

  • El usuario aalbagarcia crea un repositorio en github: https://github.com/aprendegit/fork
  • El usuario aprendegit-user1 crea un fork (bifurcación) para trabajar en él: https://github.com/aprendegit-user1/fork
  • Los dos usuarios realizan modificaciones cada uno en su repositorio, cada uno de ellos hace un commit y posteriormente un push. Cada uno sube los cambios a su correspondiente repositorio
  • El usuario aprendegit-user1 configura un repositorio remoto adicional (upstream) e incorpora, haciendo un merge, los cambios en el código que hizo aalbagarcia. Después de hacer el merge, aprendegit-user1 hace un push para actualizar su repositorio remoto.

Lo último que nos falta por hacer es que el usuario aalbagarcia, que es el propietario del repositorio inicial (https://github.com/aprendegit/fork), incorpore el trabajo del usuario aprendegit-user1 que se encuentra en el fork https://github.com/aprendegit-user1/fork.

¿Qué es un pull request?

Un pull request es una petición que el propietario de un fork de un repositorio hace al propietario del repositorio original para que este último incorpore los commits que están en el fork. En el caso que nos ocupa, el usuario aprendegit-user1 le enviará la petición a aalbagarcia para que este último incorpore los commits que tiene en su fork.

Lo primero que hará el usuario aprendegit-user1 será crear una rama que apuntará al último commit que ha hecho y que contiene las modificaciones a la página de inicio. El procedimiento es el de siempre:Creando una rama antes de hacer el pull request

  • Se selecciona a la izquierda la rama master y se hace clic sobre el último commit de la rama
  • Se hace click sobre el icono “Branch”
  • Se introduce el nombre de la rama, en este maso mycommits
  • Se hace clic sobre “Create Branch”

Si se usa la línea de comandos, la secuencia sería:

$ git checkout master
Switched to branch 'master'
$ git checkout -b mycommits
Switched to a new branch 'mycommits'

Una vez creada la rama, el usuario aprendegit-user1 hace push de la rama “mycommits” a su fork:

  • Se selecciona la rama mycommits a la izquierda asegurándonos de que esta queda como rama activa haciendo doble clic sobre ella
  • Se selecciona el último commit de la rama
  • Se hace clic sobre el icono Push de la bara de herramientas
  • En el desplegable, se selecciona en la columna “Push?” la rama mycommits y se marca en la columna de la derecha (Track) la rama local como tracking branch.
  • Se hace clic sobre OK.
La secuencia de comandos sería 
$ git checkout mycommits
$ git push -u origin mycommits
Total 0 (delta 0), reused 0 (delta 0)
To [email protected]:aprendegit-user1/fork
    * [new branch] mycommits -> mycommits
Branch mycommits set up to track remote branch mycommits from origin.

Al terminar, el estado del repositorio es el siguiente:

Solicitando el pull request

En este momento, el usuario aprendegit-user1 accede a su cuenta de github y abre en su navegador la página de su fork https://github.com/aprendegit-user1/fork.

Una vez hemos accedido, cambiamos a la rama mycommits como se indica en la siguiente captura:Acceder a github y cambiar a la rama mycommits

Una vez se ha cambiado a la rama mycommits, aprendegit-user1 hace clic sobre el botón “Pull Request”El botón pull request

Esta es la pantalla que se presenta a aprendegit-user1:Pantalla para enviar el pull request

En la parte superior, aprendegit-user1 selecciona la rama que contiene los commits que aalbagarcia (el destinatario del pull request) debe incorporar en su repositorio. En la parte de abajo se ven tres pestañas en las que se puede:

  • Poner un título y descripción al pull request
  • Ver los commits que aalbagarcia incorporará al repositorio si acepta el pull request (pestaña Commits)
  • Ver un diff que los cambios que se incluyen en los commits (pestaña Files Changed)

Es una buena práctica poner un título y descripción que reflejen el motivo del commit. Estos pull requests los ven todos los colaboradores del proyecto (si el proyecto es público lo ve todo el mundo) Así que aunque aalbagarcia y aprendegit-user1 hayan hablado por teléfono acerca de este pull request, el resto del mundo seguramente no ha escuchado la conversación. Pensando en el resto del equipo, aprendegit-user1 incluye un mensaje descriptivo de qué contiene el pull request. Cuando termina, hace clic sobre el botón “Send Pull Request”. Esta es la pantalla a la que aprendegit-user1 llega después de enviarlo:Pantalla del pull request que ve aprendegit-user1

La captura es bastante sencilla de entender. Vemos el título y descripción introducidos por aprendegit-user1, los commits y una interfaz para intercambiar comentarios con el equipo.

Aunque en pequeño, se nos indica qué es lo que tendríamos que hacer para añadir commits a este pull request: enviar más commits a la rama “mycommits” del fork de aprendegit-user1.

¿Porqué podemos necesitar añadir más commits? Imagínate que el equipo revisa el pull request y se determina que todavía queda trabajo pendiente de hacer. ¿Cómo se procede? aprendegit-user1 continúa el trabajo en la rama rama “mycommits” de su fork y cuando termina lo sube a su repositorio remoto. El pull request se actualiza y todo el equipo puede ver el nuevo código. Esto lo veremos en detalle en otro artículo, de momento, seguimos con el proceso.

Aceptando el pull request

Cuando aprendegit-user1 envía el pull request, Github envía al propietario un email avisándole de que tiene un pull request listo para revisar. En este caso, el usuario aalbagarcia recibe el email, accede a su cuenta de Github y va a su repositorio https://github.com/aprendegit/fork:Página del propietario del repositorio después del pull request

En esta pantalla, seleccionamos la pestaña “Pull Requests” y accedemos a una interfaz que nos muestra todos los que tenemos. Dado que este es el primero, en este listado seleccionamos el único que hay:Listado de pull requests del repositorio

Cuando aalbagarcia selecciona “Añadiendo logotipo”, accede a una pantalla muy parecida a la que hemos visto con el usuario aprendegit-user1. En la siguiente captura indico cuáles son las diferencias:La página del pull request vista por el propietario

Las diferencias son:

  • Existe un botón “Merge pull request” que el propietario aalbagarcia utilizará para incorporar los commits al repositorio
  • Existe un botón “Close” que el propietario utiliza para cerrar el pull request sin incorporar los cambios

Una vez revisado el código y confirmado que todo está bien, aalbagarcia hace clic sobre el botón “Merge Pull Request”. En ese momento Github le pedirá que introduzca un comentario para el merge commit. Una vez introducido, aalbagarcia hace clic sobre el botón “Commit merge” y ya está, Github automáticamente cierra el pull request. También envía un email a los dos interesados (aalbagarcia y aprendegit-user1) avisándoles de que se han incorporado los cambios en el repositorio.

Si volvéis a la página de commits del repositorio en github (https://github.com/aprendegit/fork/commits/master) veréis que tras hacer el pull request, aparece un nuevo commit en el repositorio:Merge commit tras el pull request

¿Cómo quedan los repositorios de aalbagarcia y aprendegit-user1?

En este momento, el repositorio remoto de aalbagarcia ya contiene el merge commit que se ha creado a través del pull request. La pregunta es ¿el de aprendegit-user1 también? ¿verán estos nuevos commits los dos usuarios?

…la respuesta es que, efectivamente, no lo verán hasta que hagan un fetch en sus respetivos repositorios. Tras hacer los dos usuarios un fetch de todos sus repositorios remotos (recuerda que aprendegit-user1 tiene 2 remotos,  origin y upstream) así quedan sus respectivas copias de trabajo:

Copias de trabajo después del pull request y el fetch

Para terminar:

  • aalbagarcia tiene que hacer un merge de la rama origin/master a la rama master
  • aprendegit-user1 tiene que hacer un merge de la rama upstream/master a la rama master y después hacer un push de su rama master

Una vez hecho esto, los repositorios quedan de la siguiente manera:

Copias de trabajo después de macer merge de las ramas remotas

Y como podéis ver, están sincronizados.

¿Quieres hace un pull request?

Si quieres hacer tú mismo el proceso para ver cómo funciona, ve al repositorio https://github.com/aprendegit/fork, haz un fork y envíanos las modificaciones siguiendo los pasos que hemos seguido en esta serie de artículos. Si tienes alguna duda no dudes en preguntarnos.

Seguiremos hablando de pull requests, aunque eso ya será en otros artículos.

Mantener tu fork al día

En la entrada anterior vimos qué significa hacer un fork y cómo hacerlo desde github. Resumo brevemente los pasos que dimos:

  1. El usuario aprendegit-user1 hizo un fork del repositorio https://github.com/aprendegit/fork
  2. El usuario aprendegit-user1 modificó la página de inicio del proyecto (ficticio) que estamos usando e hizo un push de sus modificaciones a su fork (https://github.com/aprendegit-user1/fork)
  3. Vimos cómo las modificaciones que aprendegit-user1 hizo a su fork no se “sincronizan” automáticamente con el repositorio original

A la vez que prendegit-user1 ha avanzado con su tarea, nuestro primer usuario (aalbagarcia) y administrador del repositorio original (https://github.com/aprendegit/fork), ha continuado también trabajando. A la vez que el usuario aprendegit-user1 ha cambiado la página de inicio, aalbagarcia ha añadido un nuevo campo a la clase Post de nuestro blog. Cuando aalbagarcia ha acabado su trabajo, lo sube al repositorio original (https://github.com/aprendegit/fork) haciendo un push.

El estado de ambos repositorios es el siguiente:

Situación de los repositorios de aalbagarcia y aprendegit-user1

En la parte superior de la imagen tenemos una captura del estado del repositorio de aprendegit-user1 (fork) y en la parte inferior una captura del repositorio de aalbagarcia. Vemos que cada uno tiene en su repositorio su trabajo. Ha llegado la hora de sincronizarlos, cosa que haremos en dos pasos:

  • Paso 1: aprendegit-usuario1 traerá a su fork el trabajo de aalbagarcia (en este caso el commit c3e3f5b que podéis ver arriba)
  • Paso 2: aalbagarcia incluirá en el repositorio original el trabajo de aprendegit a través de un pull request.
¡Empezamos por el Paso 1!

Trabajando con múltiples repositorios remotos

Lo primero que aprendgit-user1 tiene que hacer es añadir el repositorio original a su lista de remotes. El usuario aprendegit-user1 abre SourceTree y va a Repository->Repository settings:

Preferencias del repositorio

Dentro de la pantalla de “Repository settings”, selecciona la pestaña “Remotes”. En esta pantalla está su fork (origin). Se hace clic sobre el botón “Add” para añadir el repositorio original:

Seleccionando nombre y URL de nuevo remote

En la ventana emergente, se introduce “upstream” como nombre del remote (upstream es una sugerencia, podéis poner otro si lo preferís) y se pone la URL del repositorio original (https://github.com/aprendegit/fork). Rellenado el formulario, se hace clic en OK y de nuevo clic en OK en la ventana de preferencias. Una vez cerradas todas las ventanas de diálogo, el repositorio de aprendegit-user1 tendrá este aspecto:

Aspecto del repositorio tras añadir upstream

En la sección “REMOTES” aparece junto a origin el nuevo origen upstream, pero si se despliega el contenido veremos que está vacío. Pulsando sobre “Fetch” descargaremos el contenido del repositorio remoto “upstream”:

Fetch

…y cuando el fetch finaliza, el repositorio queda de la siguiente manera:

Situación del fork después de hacer fetch de upstream

El fork de aprendegit-user1 ya muestra las ramas del repositorio original ¿véis el commit c3e3f5b? ¡ya lo tenemos ahí!. ¿Qué nos falta? Pues tan sólo hacer un merge de la rama upstream/master a la rama master para “sincronizar” el fork con el original. Aprendegit-user1 selecciona el commit correspondiente a nuestra rama master (en la captura anterior ya está seleccionado) y hace clic sobre el icono merge en la barra de herramientas:

Incorporando (merge) del repositorio original al fork

En la pantalla de merge, se selecciona el commit correspondiente a la rama upstream/master y se hace clic sobre OK. Cuando el merge termina, así queda el repositorio de aprendegit-user1:

Estado del fork tras incorporar los cambios de aalbagarcia

¡Ya está! aprendegit-user1 ya tiene su rama sincronizada con el repositorio original. Ahora sólo queda hacer un push; como se puede ver el propio SourceTree nos avisa de que la rama master de aprendegit-user1 está dos commits por delante de la rama remota origin/master. Basta con hacer clic sobre el icono push para que aprendegit-user1 actualice su repositorio remoto.

Cuando aprendegit-user1 termina, así quedan su repositorio (fork) y el de aalbagarcia (original):

Estado del fork y repositorio original tras el merge

¡aalbagarcia todavía no tiene en su repositorio el trabajo de aprendegit-user1! Para eso, aprendegit-user1 hará un pull request… en la siguiente entrada.

¡Happy gitting!

Fork de repositorios en Github

¿Qué es un fork?

La palabra fork se traduce al castellano, dentro del contexto que nos ocupa, como bifurcación. Cuando hacemos un fork de un repositorio, se hace una copia exacta en crudo (en inglés “bare”) del repositorio original que podemos utilizar como un repositorio git cualquiera. Después de hacer fork tendremos dos repositorios git idénticos pero con distinta URL. Justo después de hacer el fork, estos dos repositorios tienen exactamente la misma historia, son una copia idéntica. Finalizado el proceso, tendremos dos repositorios independientes que pueden cada uno evolucionar de forma totalmente autónoma. De hecho, los cambios que se hacen el repositorio original NO se transmiten automáticamente a la copia (fork). Esto tampoco ocurre a la inversa: las modificaciones que se hagan en la copia (fork) NO se transmiten automáticamente al repositorio original.

¿Y en qué se diferencia un fork de un clon?

Cuando hacemos un clon de un repositorio, te bajas una copia del mismo a tu máquina. Empiezas a trabajar, haces modificaciones y haces un push. Cuando haces el push estás modificando el repositorio que has clonado.

Cuando haces un fork de un repositorio, se crea un nuevo repositorio en tu cuenta de Github o Bitbucket, con una URL diferente (fork). Acto seguido tienes que hacer un clon de esa copia sobre la que empiezas a trabajar de forma que cuando haces push, estás modificando TU COPIA (fork). El repositorio original sigue intacto. Lo vamos a ver en breve con un ejemplo.

¿Para qué sirve?

Tiene varios usos. El más común es el de permitir a los desarrolladores contribuir a un proyecto de forma segura.

¿Porqué decimos de forma segura? Imaginaos un super proyecto como puede ser el código fuente de Apache. ¿Cómo se trabajaba antes de existir git? con Subversion o CVS existía un servidor centralizado que tenía dos tipos de usuarios: lo que podían “escribir” en el repositorio (subir cambios al código fuente) y los que sólo podían “leer” el repositorio. Estos últimos sólo podían bajarse el código a su máquina y podían modificarlo sólo en su copia local. No podían subir ninguna modificación al servidor central.

¿Qué tenías que hacer para contribuir? Tenías que solicitar permiso de escritura y que alguien te lo diese. Una vez te lo concedían, ya podías subir tus modificaciones y, por supuesto, liarla si no sabías lo que estabas haciendo. Otra opción era enviar parches, trabajar con ramas… había varias formas pero todas bastante engorrosas.

Además, este procedimiento de dar acceso de escritura a un repositorio centralizado es un poco arriesgado. Siguiendo con el ejemplo que he puesto de Apache ¿cómo sé yo, responsable del repositorio, que esta persona que está a 10000Km de mí en la otra punta del planeta sabe lo que está haciendo? ¿puedo confiar en él?. Al final, contribuir a un proyecto se convertía en una tarea tediosa tanto para el que pretendía contribuir como para el que lo tenía que gestionar. Y no hablemos de lo divertido que era hacer un merge…

Git, al tratarse de un sistema distribuido, resuelve este tipo de problemas de una forma muy elegante a través de los forks. Digamos que Pepito es una persona quiere contribuir al proyecto. Ha encontrado un bug y sabe cómo corregirlo. Como propietario del repositorio me interesa que Pepito pueda enviarme el parche de forma rápida, que no pierda mucho tiempo. Si es así ¡Pepito estará encantado de colaborar con nosotros! ;-). Además, necesito que el proceso sea ágil, no quiero tener que invertir 5 horas de mi tiempo cada vez que tenga que hacer un merge del trabajo que Pepito me envíe. ¿Cómo resuelve git el problema?

  1. Pepito hace un fork de mi repositorio, para lo que sólo necesito darle permiso de lectura.
  2. Pepito trabaja en SU COPIA (fork) del repositorio. Como es suya, puede hacer lo que quiera, la puede borrar, corromper, dinamitar, reescribir la historia del proyecto… nos da lo mismo, es SU COPIA (fork).
  3. Cuando Pepito termina de programar y testear el parche, me avisa de que ya lo tiene y me dice “En la rama parche_de_pepito de MI COPIA (fork), tienes el parche que corrige el Bug XXXX”.
  4. Yo voy a su repositorio, miro lo que ha hecho y si está bien lo incorporo (merge) a mi repositorio, que es el original.

Las ventajas de este proceso son las siguientes:

  1.  Pepito trabaja con SU COPIA. En ningún momento le tengo que dar acceso al repositorio central.
  2. El proceso de incorporación de los cambios de Pepito es muy sencillo. Si no hay conflictos en los ficheros puede que sea tan simple como ejecutar un par de comandos git.
  3. Pepito tiene muy fácil contribuir, no le cuesta esfuerzo.
  4. Yo puedo gestionar muy fácilmente las contribuciones de muchas personas ¡me cuesta muy poco trabajo!
Ahora cierra los ojos e imagina que esto mismo lo pudieses hacer con tus compañeros de trabajo, en tu equipo…

Haciendo Fork de un repositorio en Github

Bueno, vamos a ver esto con un ejemplo práctico. La situación es la siguiente: en nuestra organización, www.aprendegit.com, tenemos un repositorio de un proyecto RubyOnRails y que usaremos a modo de ejemplo. Este repositorio se encuentra en la siguiente URL: https://github.com/aprendegit/fork. Podéis reproducir los pasos que vamos a dar a continuación con vuestra cuenta de github.

Para ayudarnos con el desarrollo de este proyecto, contamos con la ayuda de varias personas:

  1. El usuario aalbagarcia (que soy yo) y que es uno de los administradores del repositorio y de la organización.
  2. El usuario aprendegit-user1, que es un colaborador altruista que quiere ayudarnos con la web.
  3. Vosotros: si hacéis el tutorial y seguís los pasos (tened en cuenta que habrá dos entregas más) acabaréis enviándonos vuestras “mejoras ficticias” a través de un pull request.

No dudamos de las buenas intenciones de aprendegit-user1 ni de sus capacidades y aptitudes (ni de las vuestras tampoco). Aún así, siguiendo las buenas prácticas en el uso de git, aprendegit-user1 sólo tendrá permiso de lectura en el repositorio https://github.com/aprendegit/fork.

Si no tiene permiso de escritura, el usuario aprendegit-user1 podrá clonar el repositorio (porque es público) pero no podrá hacer un push. De poco le va a servir clonarlo y trabajar sobre él si luego no va a poder hacer un push ¿qué debe hacer? Hacer un fork.

El usuario aprendegit-user1 va a github, accede con su usuario y contraseña y abre la URL del repositorio original https://github.com/aprendegit/fork

En la página del repositorio, aprendegit-user1 hace clic sobre el botón fork. Al hacer clic, Github va a crear un nuevo repositorio en su cuenta que es una copia del repositorio aprendegit/fork:

github está haciendo un fork del repositorio de aprendegit

Cuando el proceso de forking termina (puede durar varios minutos si el repositorio que estamos bifurcando es muy grande) aprendegit-user1 acaba en la siguiente pantalla:

 

Este repositorio es una copia del original (https://github.com/aprendegit/fork). Si comparáis la historia de los dos repositorios veréis que es idéntica.

Este nuevo repositorio (https://github.com/aprendegit-user1/fork) es el que nuestro usuario aprendegit-user1 va a utilizar para trabajar y, cuando termine, enviarnos sus modificaciones.

aprendegit-user1 empieza a colaborar con nosotros

La primera tarea que aprendegit-user1 va a hacer como colaborador nuestro es modificar la página de inicio añadiendo nuestro logo. Para ello, clonará su fork y trabajará sobre él como si fuese un repositorio normal. Dado que el fork está en su cuenta, él es el propietario y como tal  podrá hacer push sin ningún problema. Recordad que al repositorio original (https://github.com/aprendegit/fork) este usuario no puede hacer push.

Al cabo de unos minutos, aprendegit-user1 ha clonado su repositorio (https://github.com/aprendegit-user1/fork) en su máquina, ha añadido el logo y ha hecho un push a su fork:

Si volvéis al repositorio original (https://github.com/aprendegit/fork) veréis que este sigue igual, las modificaciones que aprendegit-user1 ha subido están sólo en el fork de aprendegit-user1.

Misión cumplida: aprendegit-user1 ya está trabajando en su repositorio sin preocuparnos ninguno de los dos de que algo salga mal.

Esto es todo por hoy. En la siguiente entrada veremos qué ocurre si después de que aprendegit-user1 ha hecho un fork, nuestro administrador (aalbagarcia) sube cambios al repositorio original ¿cómo actualiza aprendegit-user1 su fork?.

¡Happy gitting!

Git Workflows: el tema que más interés despierta

Hace unos días os pedimos ayuda a través de un formulario para enfocar el contenido del blog a lo que más os interesa.

Queremos dar las gracias en primer lugar a todos los que os habéis tomado el tiempo de rellenar el formulario. A partir de los siguientes posts enfocaremos el contenido a lo que nos habéis pedido.

Resultados: Git Workflows, CLI y git-config

Con respecto al contenido, lo que más interés ha suscitado es lo relacionado con Workflows de git, seguido de la línea de comandos y la configuración con git-config.

Resultados: 30% Workflows, 19% Configuración con git-config, 19% Línea de comandos, 11% Github, 11% Crear mi servidor git, 7% GUIs, 4% Bitbucket.

También nos habéis convencido de que empecemos a grabar vídeos, así que en las próximas semanas empezaremos a hacerlo:

¿Prefieres vídeo o tutorial?

Resultados: 40% Las dos cosas, 30% Ver un vídeo, 30% Leer un tutorial

Con respecto a vuestros conocimientos, poco más de la mitad (60%) trabajáis con vuestro repositorio remoto y sabéis hacer pull y push. Sin embargo, pocos sois los que habéis trabajado con repositorios remotos, muy necesarios para poder implementar workflows en equipos distribuidos:

Conocimientos

Resultados: 60% Trabajo con mi repositorio haciendo pull y push, 20% ¡apenas se instalarlo!, 10% se crear ramas y hacer un merge, 10% Trabajo con múltiples repositorios remotos y hago pull request a diario.

Entre los que nos habéis respondido, hay un porcentaje importante que todavía no trabajáis con remotos (30%). ¡Eso hay que cambiarlo!.

Conclusión

Empezaremos a generar contenido tanto en formato tutorial y vídeo relacionado con trabajo con múltiples ramas, git workflows y configuración de git. ¡Sin olvidarnos por supuesto de aquellos que estáis empezando!

De nuevo muchas gracias por vuestra ayuda.

¿Sobre qué te gustaría que hablásemos?

El objetivo de este blog es que sea útil, y para que sea útil necesitamos tu ayuda. Cuéntanos qué te gustaría saber de git o sobre qué te gustaría que profundizásemos ¿flujos de trabajo? ¿configuración? ¿palabrejas raras como cherry picking o rebase? También puedes envíarnos una pregunta para que la convirtamos en un post.

¡Te estamos escuchando! ¡aprovecha y pide, que es gratis!

Opciones del comando git add

Un comando con el que todos estamos familiarizados es git add. Cuando nos iniciamos en el uso de git, este es de los que no faltan en las recetas que podemos en ver en cualquier tutorial. Es de los primeros que empezamos a utilizar cuando aprendemos git ¡En el libro de git de Scott Chacon aparece en la sección 2.2!

Es una pieza fundamental del flujo básico de git ya que es el comando que mueve al índice las modificaciones que hayamos realizado. El índice es un snapshot del contenido del área de trabajo en un momento dado. Este snapshot es el que posteriormente se convertirá en un commit.

La receta de git add

La forma más habitual de invocar el comando git-add es:

$ git add .

Este comando añade al índice cualquier fichero nuevo o que haya sido modificado:

$ git add .
$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
#       new file: app/assets/javascripts/home.js.coffee
#       new file: app/assets/stylesheets/home.css.scss
#       new file: app/controllers/home_controller.rb
#       new file: app/helpers/home_helper.rb
#       new file: app/views/home/index.html.erb
#       modified: config/database.yml
#       modified: config/routes.rb
#       new file: test/functional/home_controller_test.rb
#       new file: test/unit/helpers/home_helper_test.rb
#
# Changes not staged for commit:
# (use "git add/rm <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
#       deleted: app/assets/images/rails.png

Sin embargo, los ficheros borrados no se actualizan en el índice. En este caso, tendríamos que ejecutar el comando git rm app/assets/images/rails.png:

$ git rm app/assets/images/rails.png
rm 'app/assets/images/rails.png'
$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# deleted: app/assets/images/rails.png
# new file: app/assets/javascripts/home.js.coffee
# new file: app/assets/stylesheets/home.css.scss
# new file: app/controllers/home_controller.rb
# new file: app/helpers/home_helper.rb
# new file: app/views/home/index.html.erb
# modified: config/database.yml
# modified: config/routes.rb
# new file: test/functional/home_controller_test.rb
# new file: test/unit/helpers/home_helper_test.rb
#

Las opciones -u y -A del comando git-add añaden al índice los ficheros eliminados, aunque gestionan de manera diferente los ficheros nuevos. Veamoslo usando este mismo ejemplo.

git-add -u

Partimos de la siguiente área de trabajo:

$ git status
# On branch master
# Changes not staged for commit:
# (use "git add/rm <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
#    deleted: app/assets/images/rails.png
#    modified: config/routes.rb
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
#    app/assets/javascripts/home.js.coffee
#    app/assets/stylesheets/home.css.scss
#    app/controllers/home_controller.rb
#    app/helpers/home_helper.rb
#    app/views/home/
#    test/functional/home_controller_test.rb
#    test/unit/helpers/
no changes added to commit (use "git add" and/or "git commit -a")

La opción -u sólo añade al índice aquellos ficheros que ya estén siendo monitorizados por git, así que en este caso, únicamente se subirán al índice rails.png y routes.rb:

$ git add -u
$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
#    deleted: app/assets/images/rails.png
#    modified: config/routes.rb
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
#    app/assets/javascripts/home.js.coffee
#    app/assets/stylesheets/home.css.scss
#    app/controllers/home_controller.rb
#    app/helpers/home_helper.rb
#    app/views/home/
#    test/functional/home_controller_test.rb
#    test/unit/helpers/

La opción -u acepta un patrón de búsqueda. Si este patrón está vacío, el resultado es que se actualicen todos los ficheros borrados o modificados en el área de trabajo. Si el patrón no está vacío, sólo se actualizarán en el índice los ficheros que encajen con el patrón. En el siguiente ejemplo, ejecutamos el mismo comando para añadir únicamente los ficheros de la carpeta config:

$ git add -u config/*
$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
#    modified: config/routes.rb
#
# Changes not staged for commit:
# (use "git add/rm <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
#    deleted: app/assets/images/rails.png
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
#    app/assets/javascripts/home.js.coffee
#    app/assets/stylesheets/home.css.scss
#    app/controllers/home_controller.rb
#    app/helpers/home_helper.rb
#    app/views/home/
#    test/functional/home_controller_test.rb
#    test/unit/helpers/

git-add -a

Esta opción funciona como la opción -u añadiendo también a la búsqueda los ficheros del área de trabajo. El resultado es que los ficheros que no estén siendo monitorizados también se añadirán al índice.

Partimos de la siguiente situación:

$ git status
# On branch master
# Changes not staged for commit:
# (use "git add/rm <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
#    deleted: app/assets/images/rails.png
#    modified: config/routes.rb
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
#    app/assets/javascripts/home.js.coffee
#    app/assets/stylesheets/home.css.scss
#    app/controllers/home_controller.rb
#    app/helpers/home_helper.rb
#    app/views/home/
#    test/functional/home_controller_test.rb
#    test/unit/helpers/
no changes added to commit (use "git add" and/or "git commit -a")

Al ejecutar el comando git add -A, se añadirán al índice los ficheros borrados, los modificados y los nuevos:

$ git add -A
$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
#    deleted: app/assets/images/rails.png
#    new file: app/assets/javascripts/home.js.coffee
#    new file: app/assets/stylesheets/home.css.scss
#    new file: app/controllers/home_controller.rb
#    new file: app/helpers/home_helper.rb
#    new file: app/views/home/index.html.erb
#    modified: config/routes.rb
#    new file: test/functional/home_controller_test.rb
#    new file: test/unit/helpers/home_helper_test.rb

Al igual que la opción -u, esta opción también acepta un patrón. En el siguiente ejemplo, actualizamos el índice con las modificaciones, ficheros nuevos y ficheros borrados sólo de la carpeta app/assets:

$ git add -A app/assets
$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
#    deleted: app/assets/images/rails.png
#    new file: app/assets/javascripts/home.js.coffee
#    new file: app/assets/stylesheets/home.css.scss
#
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
#    modified: config/routes.rb
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
#    app/controllers/home_controller.rb
#    app/helpers/home_helper.rb
#    app/views/home/
#    test/functional/home_controller_test.rb
#    test/unit/helpers/

git-add -n

Esta opción es muy práctica ya que nos mostrará en pantalla lo que el comando git-add haría sin actualizar el índice. Continuando con el comando anterior (git add -A app/assets) si quisiésemos ver qué ficheros se actualizarán en el índice sin realmente actualizarlos, haríamos los siguiente:

$ git add -n -A app/assets
remove 'app/assets/images/rails.png'
add 'app/assets/javascripts/home.js.coffee'
add 'app/assets/stylesheets/home.css.scss'

Resumen

Hemos visto tres opciones del comando git-add: -u, -A y -n. Las dos primeras nos permiten actualizar en el índice directamente ficheros borrados sin necesidad de ejecutar el comando git-rm. La última opción, -n, simula lo que hará el comando git-add sin realmente actualizar el índice. Los tres son opciones útiles que de haberlas conocido cuando empecé con git hace años me habrían ahorrado unos cuantos comandos.

Referencias

Ignorando ficheros en git – Parte IV: Más patrones

En la entrega anterior estuvimos analizando los patrones básicos que podemos utilizar para ignorar ficheros a través de .gitignore, .git/info/exclude y .gitignore_local. En esta entrega veremos cómo git utiliza los patrones de la shell dentro de estos ficheros.

Todos los patrones que usa git

Hagamos un pequeño repaso de lo que ya sabemos:

  • Las líneas en blanco no se consideran un patrón. Se usan para hacer los ficheros más legibles
  • Si la linea comienza con #, se considera un comentario
  • El prefijo ! sirve para negar un patrón
  • Si el patrón termina en / sólo se aplicará a carpetas, es decir, un patrón “web/” ignorará la carpeta web/ pero no ignorará un fichero que se llame web

Hasta aquí lo que ya habíamos visto ¿qué nos falta?

  • Si el patrón no termina en /, git lo interpreta como un “shell glob pattern“. Internamente git llama a la función fnmatch con el flag FNM_PATHNAME: esto significa que ni el * ni el ? incluyen el carácter /. En seguida veremos ejemplos.
  • Una / al principio del patrón indica el inicio de una ruta relativa a la carpeta en la que se encuentre el fichero .gitignore. Una línea del tipo /config.php ignorará el fichero config.php pero no ignorará web/config.php

Shell globs en git

Los ficheros .gitignore, .git/info/exclude y .gitignore_local permiten incluir patrones de tipo shell. Si habéis trabajado con cualquier shell de Unix o el CMD de windows, estaréis familiarizados con el funcionamiento de estos patrones. En caso contrario, aquí tenéis las reglas que se siguen.

En una expresión que contenga el símbolo “?”, éste se corresponde con uno y sólo un carácter

Ejemplos:

# Ignora los ficheros bg-01.jpg bg-lt.jpg
#
# No ignora los ficheros bg-1.jpg y bg-001.jpg
#
bg-??.jpg

Este patrón ignorará los ficheros cuyos nombres empiezan por “bg-“, van seguidos exactamente de dos caracteres, y luego van seguidos de “.jpg”. Por eso el fichero bg-1.jpg no se ignora, porque entre “bg-” y “.jpg” no hay dos caracteres, sólo uno. Este ejemplo ilustra que el símbolo “?” no indica un caracter opcional.

En una expresión que contenga el símbolo ” * “, éste se corresponde con cualquier número de caracteres

Ejemplos:

# Ignora todos los ficheros acabados en .nib
#
# Ignora tanto MainWindow.nib y builds/MainWindow.nib
*.nib

#Ignora todos los ficheros que empiecen por "bg-" y acaben en ".jpg"
bg-*.jpg

En el primer ejemplo, estamos ignorando cualquier fichero que acabe en .nib, independientemente de la carpeta en la que se encuentre. En el segundo ejemplo, estamos ignorando cualquier fichero que empiece por “bg-” y acabe por “.jpg”. Una pregunta: ¿se ignorará el fichero “bg-.jpg” usando este patrón?. La respuesta la tenéis un poco más abajo.


En una expresión que contenga corchetes [ ], éstos se corresponden con uno y sólo un caracter de los que están incluidos en los corchetes.

Ejemplos:

# Ignora los ficheros *.o y *.a
*.[ao]

# Ignora los ficheros .nib y .xib
*.[xn]ib

Estos patrones no ignoran los ficheros liberia.so o los ficheros mainwindow.ib. Es necesario que alguno de los caracteres que están entre corchetes aparezcan en el fichero.

Si se necesita utilizar los caracteres ? * [ ] en un patrón, estos deberán escaparse con \

Ejemplo:

# Ignorando ficheros que contienen [ y ] en el nombre
#
# Este patrón ignorará los ficheros
# cache/cache-[hG7].cache y cache/cache-[009].cache
cache/cache-\[???\].cache

Shell globs y carpetas

¿Qué significa que git utilice el flag FNM_PATHNAME al llamar a la función fnmatch? Que los símbolos * ? y [] no incluyen el caracter ” / ” de separación de directorios.

# El uso de FNM_PATHNAME hace que el siguiente patrón ignore los ficheros
# web/fichero.html, pero no ignore el fichero web/admin/fichero.html
#
# Como el " * " no incluye " / ", el fichero web/admin/fichero.html no 
# encaja con el patrón
web/*.html

¿Qué ocurre si necesitamos justo el efecto contrario? es decir, queremos ignorar todos los ficheros .html que están en las subcarpetas de web pero no ignorar los ficheros .html que están en web. El patrón sería el siguiente:

# Ignora los ficheros .html que están en subcarpetas de la carpeta web
# No ignora los ficheros web/*.html
#
# Con este patrón, el fichero web/fichero.html se incluirá en el repositorio
# mientras que ficheros con web/admin/fichero.html o web/images/index.html se 
# ignorarán
web/**/*.html

Otra pregunta: Este patrón ¿ignora el fichero web/admin/subcarpeta/fichero.txt?

Rutas relativas

Un patrón que comienza por ” / “, indica que para decidir si el fichero se ignora o no, se utiliza una ruta relativa al fichero .gitignore:

# Ignora los fichero *.c en la carpeta raiz del proyecto: memory.c
# No ignora los ficheros en subcarpetas como modules/cache.c
/*.c

Conclusiones

En esta entrega hemos visto cómo interpreta git los patrones glob shell y los patrones a rutas relativas. En la siguiente entrega veremos cómo podemos usar múltiples ficheros .gitignore. Estos nos ayudarán a salvar las limitaciones que tenemos a la hora de trabajar con múltiples subcarpetas.

Respuestas:

  1. Efectivamente, el patrón “bg-*.jpg” ignora que fichero “bg-.jpg”. Eso es porque a diferencia de símobol “?”, el símbolo “*” se corresponde con cualquier número de caracteres, incluido cero caracteres.
  2. El patrón web/**/*.html no ignora el fichero web/admin/subcarpeta/fichero.txt. Dado que se usa el parámetro FNM_PATHNAME, el ” ** ” no incluye el caracter ” / ” y por lo tanto este patrón sólo incluye las carpetas que son hijos de web, no incluye los nietos y niveles de más profundidad en la jerarquía de carpetas.

git alias de Nicola Paolucci

Hoy una entrada corta pero muy interesante. Os recomiendo leáis este post de Nicola Paolucci en el que comparte con todos nosotros los aliases que utiliza en sus repositorios git:

Must Have Git Aliases: Advanced Examples

También podéis acceder al fichero .gitconfig que Nicola tiene en github.

Confío en que os resulte tan interesante y útil como a mí.

Ignorando ficheros en git – Parte III: Patrones

En la segunda entrega de esta serie aprendimos en qué orden se aplican los patrones para ignorar cambios en ciertos ficheros del repositorio. En esta tercera entrega veremos los patrones y reglas que git utiliza para interpretar los ficheros it ignore.

Comentarios y líneas en blanco

Podemos hacer nuestro fichero más legible si incluimos comentarios y separadores:

  • Cualquier línea que comience por # es un comentario
  • Una línea en blanco no se considera un patrón por parte de git, por lo que puede ser usada como un separador

Sé considerado con el resto de los miembros del equipo y comenta adecuadamente cada uno de los patrones que utilices. Indica el porqué de ese patrón de forma que el resto de compañeros o colaboradores sepan porqué has decidido en un momento dado ignorar ciertos ficheros. Y una cosa más, no todo el mundo usa las mismas herramientas que tú ni tiene tu mismo nivel de conocimientos en determinadas materias así que piensa un poco en los demás y ayúdales:

# Jetbrains IDEs: PHPStorm / RubyMine  
# (No todo el mundo tiene que saber que los ficheros .idea son de un 
# entorno de desarrollo)
.idea 

# Ficheros de documentación sphynx. Puedes generar tu copia local de la doc
# en /doc/build utilizando los scripts sphynx en /doc
/doc/build/

Negación

Utilizando el carácter podemos invertir un patrón ¿Qué significa invertir un patrón? Veamoslo con un ejemplo:

# Incluir expresamente en el repositorio todos los ficheros con extensión php
!*.php

¿Porqué podemos necesitar este tipo de patrones? Imagina que estás trabajando en un proyecto en PHP; como te puedes imaginar, si tu repositorio sólo tuviese estas dos líneas en los ficheros git/info/exclude, .ignore y .gitignore_local podríamos quitarlas ya que el efecto sería el mismo. Ahora bien ¿para qué podemos necesitar un patrón como este?:

  • Tal y como vimos en la anterior entrega, para invertir patrones de menor prioridad
  • Crear excepciones a patrones muy restrictivos

Veamos un ejemplo del segundo caso. Siguiendo con el ejemplo de un proyecto en PHP, podemos eliminar la línea anterior ya que no hace falta. Ahora bien ¿qué hacemos con los ficheros html?:

# Ignorar todos los ficheros .html...
*.html

 #... excepto en la carpeta web
!web/*.html

En este caso, cualquier fichero con extensión .html en cualquier carpeta se ignorará, excepto los ficheros que estén en la carpeta web. Cuidado porque ficheros .html que estén en una subcarpeta de web, como por ejemplo web/archive, también se ignorarán. Más adelante veremos porqué.

Ignorando carpetas enteras

Si un patrón acaba con una barra /, git ignorará cualquier fichero dentro de esa carpeta:

# Ignorar el contenido de las carpetas log y cache
cache/
log/

Git ignorará cualquier fichero que esté dentro de cache/ o log/ o en cualquier subcarpeta que cuelgue de ellas.

Este patrón no se lleva muy bien con la negación ¿Por qué decimos esto? Imagina que quieres ignorar el contenido de la carpeta web entera (incluyendo todas las subcarpetas que cuelgan de ella) excepto el fichero web/index.php. Con lo que sabemos hasta ahora, intentaríamos una combinación de patrones como la siguiente:

#Esto no funciona:
# git ignorará también el fichero index.php
web/
!web/index.php

Desafortunadamente esto no funciona y git ignorará fichero index.php. Veremos en una futura entrega cómo resolver este problema.

Una última nota sobre el uso de /. Si usamos el siguiente patrón

#Ignorar el contenido de la carpeta web
web/

y web no es una carpeta sino un enlace simbólico o un fichero regular:

total 16
-rw-r--r-- 1 aalba staff 0 22 dic 14:42 Alumno.php
-rw-r--r-- 1 aalba staff 0 22 dic 14:41 Curso.php
-rw-r--r-- 1 aalba staff 0 22 dic 14:42 Licencia.php
-rw-r--r-- 1 aalba staff 339 7 dic 16:39 README.md
drwxr-xr-x 3 aalba staff 238 29 dic 08:29 builds
lrwxr-xr-x 1 aalba staff 11 29 dic 08:29 web -> builds/html

¡el fichero no se ignora!

$ git status
# On branch master
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# web
  ^^^ -> el enlace simbólico o fichero regular no se ignora ya que el patrón
         web/ sólo se aplica a carpetas

Esto es todo por hoy, en la siguiente entrega de la serie veremos los patrones shell que podemos utilizar.