5.3 Git en entornos distribuidos - Manteniendo un proyecto

Si recibiste el parche de alguien que lo generó con git diff o con el comando Unix diff (lo cual no se recomienda; consulta la siguiente sección), puedes aplicarlo con el comando git apply. Suponiendo que guardaste el parche en /tmp/patch-ruby-client.patch, puedes aplicarlo de esta forma:

Esto modifica los archivos en tu directorio de trabajo. Es casi idéntico a ejecutar un comando patch -p1 para aplicar el parche, aunque es más paranoico y acepta menos coincidencias aproximadas que patch. También puede manejar archivos nuevos, borrados y renombrados si están descritos en formato git diff mientras que patch no puede hacerlo. Por último, git apply sigue un modelo “aplica todo o aborta todo”, donde se aplica todo o nada, mientras que patch puede aplicar parches parcialemente, dejando tu directorio de trabajo en un estado inconsistente. git apply es en general mucho más conservador que patch. No creará un commit por ti – tras ejecutarlo, debes preparar (stage) y confirmar (commit) manualmente los cambios introducidos.

También puedes usar git apply para comprobar si un parche se aplica de forma limpia antes de aplicarlo realmente – puedes ejecutar git apply --check indicando el parche:

Si no obtienes salida, entonces el parche debería aplicarse limpiamente. Este comando también devuelve un estado distinto de cero si la comprobación falla, por lo que puedes usarlo en scripts.

Si el colaborador es usuario de Git y conoce lo suficiente como para usar el comando format-patch para generar el parche, entonces tu trabajo es más sencillo, puesto que el parche ya contiene información del autor y un mensaje de commit. Si puedes, anima a tus colaboradores a usar format-patch en lugar de diff para generar parches. Sólo deberías usar git apply para parches antiguos y cosas similares.

Para aplicar un parche generado con format-patch, usa git am. Técnicamente, git am se construyó para leer de un archivo mbox (buzón de correo). Es un formato de texto plano simple para almacenar uno o más mensajes de correo en un archivo de texto. Es algo parecido a esto:

Esto es el comienzo de la salida del comando format-patch que viste en la sección anterior. También es un formato mbox válido. Si alguien te ha enviado el parche por e-mail usando git send-email y lo has descargado en formato mbox, entonces puedes pasar ese archivo a git am y comenzará a aplicar todos los parches que encuentre. Si usas un cliente de correo que puede guardar varios e-mails en formato mbox, podrías guardar conjuntos completos de parches en un único archivo y a continuación usar git am para aplicarlos de uno en uno.

Sin embargo, si alguien subió a un sistema de gestión de incidencias o algo parecido un parche generado con format-patch, podrías guardar localmente el archivo y posteriormente pasarlo a git am para aplicarlo:

Puedes ver que aplicó el parche limpiamente y creó automáticamente un nuevo commit. La información del autor se toma de las cabeceras From y Date del e-mail, y el mensaje del commit sale del Subject y el cuerpo del e-mail (antes del parche). Por ejemplo, si se aplicó este parche desde el archivo mbox del ejemplo anterior, el commit generado sería algo como esto:

El campo Commit indica la persona que aplicó el parche y cuándo lo aplicó. El campo Author es la persona que creó originalmente el parche y cuándo fué creado.

Pero es posible que el parche no se aplique limpiamente. Quizás tu rama principal es muy diferente de la rama a partir de la cual se creó el parche, o el parche depende de otro parche que aún no has aplicado. En ese caso, el proceso git am fallará y te preguntará qué hacer:

Este comando marca los conflictos en cualquier archivo para el cual detecte problemas, como si fuera una operación merge o rebase. Estos problemas se solucionan de la misma forma - edita el archivo para resolver el conflicto, prepara (stage) el nuevo archivo y por último ejecuta git am --resolved para continuar con el siguiente parche:

Si quieres que Git intente resolver el conflicto de forma un poco más inteligente, puedes indicar la opción -3 para que Git intente hacer un merge a tres bandas. Esta opción no está activa por defecto, ya que no funciona si el commit en que el parche está basado no está en tu repositorio. Si tienes ese commit – si el parche partió de un commit público – entonces la opción -3 es normalmente mucho más inteligente a la hora de aplicar un parche conflictivo:

En este caso, el parche ya ha sido aplicado. Sin la opción -3, aparecería un conflicto.

Si estás aplicando varios parches a partir de un archivo mbox, también puedes ejecutar el comando am en modo interactivo, el cual se detiene en cada parche para preguntar si quieres aplicarlo:

Esto está bien si tienes guardados varios parches, ya que puedes revisar el parche previamente y no aplicarlo si ya lo has hecho.

Una vez aplicados y confirmados todos los parches de tu rama puntual, puedes decidir cómo y cuándo integrarlos en una rama de largo recorrido.

Un flujo de trabajo sencillo integra tu trabajo en tu rama master. En este escenario, tienes una rama master que contiene básicamente código estable. Cuando tienes trabajo propio en una rama puntual o trabajo aportado por algún colaborador que ya has verificado, lo integras en tu rama master, borras la rama puntual y continúas el proceso. Si tenemos un repositorio con trabajo en dos ramas llamadas ruby_client y php_client, tal y como se muestra en Historial con varias ramas puntuales. e integramos primero ruby_client y luego php_client, entonces tu historial terminará con este aspecto Tras integrar una rama puntual..

Este es probablemente el flujo de trabajo más simple y puede llegar a causar problemas si estás tratando con proyectos de mayor envergadura o más estables, donde hay que ser realmente cuidadoso al introducir cambios.

Si tienes un proyecto más importante, podrías preferir usar un ciclo de integración en dos fases. En este escenario, tienes dos ramas de largo recorrido, master y develop, y decides que la rama master sólo se actualiza cuando se llega a una versión muy estable y todo el código nuevo está integrado en la rama develop. Ambas ramas se envían habitualmente al repositorio público. Cada vez que tengas una nueva rama puntual para integrar en (Antes de integrar una rama puntual.), primero la fusionas con la rama develop (Tras integrar una rama puntual.); luego, tras etiquetar la versión, avanzas la rama master hasta el punto donde se encuentre la ahora estable rama develop (Tras el lanzamiento de una rama puntual.).

De esta forma, cuando alguien clone el repositorio de tu proyecto, puede recuperar la rama master para construir la última versión estable y mantenerla actualizada fácilmente, o bien puede recuperar la rama develop, que es la que tiene los últimos desarrollos. Puedes ir un paso más allá y crear una rama de integración integrate, donde integres todo el trabajo. Entonces, cuando el código de esa rama sea estable y pase las pruebas, lo puedes integrar en una rama de desarrollo; y cuando se demuestre que efectivamente permanece estable durante un tiempo, avanzas la rama master.

El proyecto Git tiene cuatro ramas de largo recorrido: master, next, y pu (proposed updates, actualizaciones propuestas) para trabajos nuevos, y maint para trabajos de mantenimiento de versiones anteriores. Cuando los colaboradores introducen nuevos trabajos, se recopilan en ramas puntuales en el repositorio del responsable de mantenimiento, de manera similar a la que se ha descrito (ver Gestionando un conjunto complejo de ramas puntuales paralelas.). En este punto, los nuevos trabajos se evalúan para decidir si son seguros y si están listos para los usuarios o si por el contrario necesitan más trabajo. Si son seguros, se integran en la rama next, y se envía dicha rama al repositorio público para que todo el mundo pueda probar las nuevas funcionalidades ya integradas.

Si las nuevas funcionalidades necesitan más trabajo, se integran en la rama pu. Cuando se decide que estas funcionalidades son totalmente estables, se integran de nuevo en la rama master, construyéndolas a partir de las funcionalidades en la rama next que aún no habían pasado a la rama master. Esto significa que la rama master casi siempre avanza, next se reorganiza ocasionalmente y pu se reorganiza mucho más a menudo:

Cuando una rama puntual se ha integrado en la rama master, se elimina del repositorio. El proyecto Git también tiene una rama maint creada a partir de la última versión para ofrecer parches, en caso de que fuera necesaria una versión de mantenimiento. Así, cuando clonas el repositorio de Git, tienes cuatro ramas que puedes recuperar para evaluar el proyecto en diferentes etapas de desarrollo, dependiendo de si quieres tener una versión muy avanzada o de cómo quieras contribuir. De esta forma, el responsable de mantenimiento tiene un flujo de trabajo estructurado para ayudarle a aprobar las nuevas contribuciones.

Otros responsables de mantenimiento prefieren reorganizar o entresacar el nuevo trabajo en su propia rama master, en lugar de integrarlo, para mantener un historial prácticamente lineal. Cuando tienes trabajo en una rama puntual y has decidido que quieres integrarlo, te posicionas en esa rama y ejecutas el comando rebase para reconstruir los cambios en tu rama master (o develop, y así sucesivamente). Si ese proceso funciona bien, puedes avanzar tu rama master, consiguiendo un historial lineal en tu proyecto.

Otra forma de mover trabajo de una rama a otra es entresacarlo (cherry-pick). En Git, "entresacar" es como hacer un rebase para un único commit. Toma el parche introducido en un commit e intenta reaplicarlo en la rama en la que estás actualmente. Esto es útil si tienes varios commits en una rama puntual y sólo quieres integrar uno de ellos, o si sólo tienes un commit en una rama puntual y prefieres entresacarlo en lugar de hacer una reorganización (rebase). Por ejemplo, imagina que tienes un proyecto como éste:

Si sólo deseas integrar el commit e43a6 en tu rama master, puedes ejecutar

Esto introduce el mismo cambio introducido en e43a6, pero genera un nuevo valor SHA-1 de confirmación, ya que la fecha en que se ha aplicado es distinta. Ahora tu historial queda así:

En este momento ya puedes eliminar tu rama puntual y descartar los commits que no quieres integrar.

Git dispone de una utilidad llamada “rerere” que puede resultar útil si estás haciendo muchas integraciones y reorganizaciones, o si mantienes una rama puntual de largo recorrido.

Rerere significa “reuse recorded resolution” (reutilizar resolución grabada) – es una forma de simplificar la resolución de conflictos. Cuando “rerere” está activo, Git mantendrá un conjunto de imágenes anteriores y posteriores a las integraciones correctas, de forma que si detecta que hay un conflicto que parece exactamente igual a otro ya corregido previamente, usará esa misma corrección sin causarte molestias.

Esta funcionalidad consta de dos partes: un parámetro de configuración y un comando. El parámetro de configuración es rerere.enabled y es bastante útil ponerlo en tu configuración global:

Ahora, cuando hagas una integración que resuelva conflictos, la resolución se grabará en la caché por si la necesitas en un futuro.

Si fuera necesario, puedes interactuar con la caché de “rerere” usando el comando git rerere. Cuando se invoca sin ningún parámetro adicional, Git comprueba su base de datos de resoluciones en busca de coincidencias con cualquier conflicto durante la integración actual e intenta resolverlo (aunque se hace automáticamente en caso de que rerere.enabled sea true). También existen subcomandos para ver qué se grabará, para eliminar de la caché una resolución específica y para limpiar completamante la caché. Veremos más detalles sobre “rerere” en Rerere.