Git merge

Las confirmaciones de fusión son únicas con respecto a otras confirmaciones en el hecho de que tienen dos confirmaciones principales. Al crear una confirmación de fusión, Git tratará de fusionar automáticamente los historiales independientes. Sin embargo, si encuentra datos que se han cambiado en ambos historiales, no podrá combinarlos de ese modo. En ese caso, se crea un conflicto de control de versiones y Git solicitará la intervención del usuario para poder continuar.

Antes de ejecutar una fusión, hay un par de pasos de preparación que llevar a cabo con el fin de garantizar que la fusión se realice sin problemas.

Ejecuta git status para asegurarte de que HEAD apunte a la rama de fusión-recepción correcta. En caso necesario, ejecuta git checkout para cambiar a la rama de recepción. En nuestro caso, ejecutaremos git checkout main.

Asegúrate de que la rama de recepción y la rama de fusión están actualizadas con los cambios remotos más recientes. Ejecuta git fetch para incorporar los cambios de las confirmaciones remotas más recientes. Una vez que la recuperación se haya completado, asegúrate de que la rama main tenga las actualizaciones más recientes mediante la ejecución del comando git pull.

Una vez adoptados los pasos comentados anteriormente de "preparación para la fusión", se puede iniciar una fusión ejecutando git merge donde es el nombre de la rama que se fusionará con la rama de recepción.

Sin embargo, no es posible una fusión con avance rápido si las ramas han divergido. Cuando no hay un proceso lineal hacia la rama de destino, Git no tiene más opción que combinarlas mediante una fusión de 3 vías. Las fusiones de 3 vías utilizan una confirmación específica para unir dos historiales. Esta fusión recibe su nombre del hecho de que Git utiliza tres confirmaciones para generar la confirmación de fusión: los dos extremos de la rama y su predecesor común.

Aunque se pueden utilizar cualquiera de estas estrategias de fusión, a muchos desarrolladores les gusta utilizar las fusiones con avance rápido (facilitadas a través del comando rebasing) para funciones pequeñas o correcciones de errores, mientras que se reservan las fusiones de tres vías para la integración de funciones con una ejecución de mayor duración. En este último caso, la confirmación de fusión resultante sirve como una unión simbólica de las dos ramas.

Nuestro primer ejemplo muestra una fusión con avance rápido. El código a continuación crea una rama nueva, le añade dos confirmaciones y, seguidamente, la integra en la línea principal con una fusión con avance rápido.

Se trata de un flujo de trabajo común para las ramas temáticas transitorias que se utilizan más como un desarrollo aislado que como una herramienta de organización para funcionalidades con una ejecución de mayor duración.

Ten en cuenta también que Git no debería quejarse sobre el comando git branch -d, ya que ahora se puede acceder a la nueva función desde la rama principal.

En caso de necesitar una confirmación de fusión durante una fusión con avance rápido para mantener registros, es posible ejecutar git merge con la opción --no-ff.

Este comando fusiona la rama especificada en la rama actual, pero siempre genera una confirmación de fusión (incluso si se trata de una fusión con avance rápido). Esto resulta útil para documentar todas las fusiones que tienen lugar en tu repositorio.

El siguiente ejemplo es muy similar, pero requiere una fusión de tres vías porque la rama main ha avanzado mientras la función se está desarrollando. Este es un caso habitual con funciones grandes o cuando hay varios desarrolladores trabajando en un proyecto simultáneamente.

Ten en cuenta que es imposible que Git lleve a cabo una fusión con avance rápido, ya que no hay forma de mover la rama main a la de new-feature sin retroceder.

En la mayoría de los flujos de trabajo, la rama de new-feature sería una función muy grande que ha tardado mucho en desarrollarse, por lo que, mientras tanto, se han ido incorporando nuevas confirmaciones a la rama main. Si tu rama de función fuera en realidad tan pequeña como la del ejemplo anterior, probablemente sería mejor que la fusionases mediante cambio de base a la rama main y que hicieses una fusión con avance rápido. Esto evitaría que apareciesen confirmaciones de fusión superfluas en el historial del proyecto.

Si las dos ramas que tratas de fusionar han cambiado la misma parte del mismo archivo, Git no podrá averiguar qué versión utilizar. Cuando esto ocurre, Git se detiene justo antes de la confirmación de fusión para que puedas resolver los conflictos manualmente.

Algo muy interesante del proceso de fusión de Git es que utiliza el conocido flujo de trabajo de edición, preparación y confirmación para resolver los conflictos de fusión. Cuando se observa un conflicto de fusión, la ejecución del comando git status muestra qué archivos se deben resolver. Por ejemplo, si en ambas ramas se ha modificado la misma sección de hello.py, se vería algo parecido a esto:

Si Git encuentra un conflicto durante una fusión, editará el contenido de los archivos afectados con indicadores visuales que marquen ambas caras del contenido conflictivo. Estos marcadores visuales son: <<<<<<<, =======, y>>>> >>>. Es útil buscar estos indicadores en un proyecto durante una fusión para saber dónde hay que resuelto los conflictos.

Normalmente, el contenido que se encuentra delante del marcador ======= es la rama de recepción y el de la parte de detrás es la rama de fusión.

Una vez identificadas las secciones conflictivas, puedes entrar y arreglar la fusión a tu gusto. Cuando estés listo para terminar la fusión, lo único que tienes que hacer es ejecutar git add en los archivos conflictivos para indicar a Git que se han resuelto. Seguidamente, ejecutas un git commit normal para generar la confirmación de fusión. El proceso es exactamente el mismo que el de la confirmación de una instantánea normal, lo que significa que es fácil para los desarrolladores habituales gestionar sus propias fusiones.

Ten en cuenta que los conflictos de fusión solo se producirán en el caso de una fusión de 3 vías. Los cambios conflictivos en una fusión de avance rápido no son posibles.

Este documento es un resumen del comando git merge. La fusión es un proceso esencial cuando se trabaja con Git. Hemos hablado de los mecanismos internos que hay detrás de una fusión y de las diferencias entre una fusión con avance rápido y una de 3 vías auténtica. Algunas de las principales conclusiones son las siguientes:

1. La fusión en Git combina secuencias de confirmaciones en un solo historial unificado de confirmaciones.

2. En Git hay, principalmente, dos tipos de fusión: con avance rápido y de tres vías.

3. Git permite fusionar las confirmaciones automáticamente salvo que haya cambios que entren en conflicto en ambas secuencias de confirmación.

Este documento ha integrado y hecho referencia a otros comandos de Git como, por ejemplo: git branch, git pull y git fetch. Para obtener más información sobre ellos, visita sus respectivas páginas.