Con el trabajo que se realiza en un proyecto de desarrollo, Git es todo un regalo del cielo. Sin embargo, si tienes muchos actores en la pista de baile, uno o dos pisarán los pies de los demás. Para tu proyecto, esto significa que dos desarrolladores pueden trabajar en el mismo conjunto de código y ambos pueden hacer commits. Para estas situaciones, necesitas recurrir a algunas estrategias merge de Git para resolver el conflicto.
Aunque un merge de Git puede ser sencillo, hay muchas otras ocasiones en las que necesitas un enfoque avanzado. En estos casos utilizarás estrategias como el merge recursivo, merges tripartitos, y muchas más. Incluso puede que necesites deshacer un merge de Git en algún momento.
Este tutorial mostrará algunas técnicas complejas de merge de Git para añadir a tu repertorio. De hecho, ¡vamos a meternos de lleno en lo bueno!
Introducción a las Estrategias de Merge de Git
El concepto básico de merge es sencillo: se unen dos ramas para convertir varios commits en uno. Sin embargo, hay una serie de técnicas que puedes emplear para asegurarte de que confirmas y fusionas el código correcto.
Vamos a ver algunas estrategias importantes que debes comprender. No están en ningún orden, y en algún momento de tu carrera como desarrollador, puede que las necesites todas. Además, también necesitarás una sólida comprensión de los conceptos básicos de Git, como punteros, ramas y confirmaciones.
La Diferencia entre Merges Bidireccionales y Tridireccionales
Es útil comprender la diferencia entre un merge bidireccional y su compañero tridireccional. La mayoría de las estrategias de merge que veremos a continuación se refieren a situaciones tripartitas. De hecho, es más sencillo hablar de lo que es un merge a tres bandas. Considera el siguiente ejemplo:
- Tienes una rama principal con varios commits y una rama de características que también tiene commits.
- Sin embargo, si ahora la rama principal realiza más commits, ambas ramas divergirán.
- En términos sencillos, tanto la rama principal como la rama de características tienen commits que la otra no tiene. Si las fusionas utilizando un enfoque bidireccional, perderás un commit (probablemente en la principal).
- En su lugar, Git creará un nuevo commit de merge a partir de la rama principal y de la rama de características actuales.
En pocas palabras, Git mirará tres instantáneas diferentes para fusionar los cambios: la cabecera de la principal, la cabecera de la rama de características y el ancestro común. Este será el commit final común a la rama principal y a la rama de características.
En la práctica, no tendrás que preocuparte de si una determinada estrategia merge es bidireccional o tridireccional. Muchas veces, tendrás que utilizar una estrategia independientemente. En cualquier caso, es útil saber cómo «piensa» Git cuando se trata de fusionar ramas y repos.
Merge Fast-Forward
La primera estrategia puede que no necesite que realices ninguna acción para llevarse a cabo. Un merge fast-forward desplaza el puntero al último commit en la principal sin crear un commit adicional (lo que puede resultar confuso.) Es un enfoque limpio que muchos desarrolladores utilizarán como estándar.
La técnica comienza con una rama principal que puede o no tener commits. En este caso, abres una nueva rama, trabajas en el código y haces commits. En este punto, también tienes que fusionar esos cambios de nuevo con la principal. Una fusión rápida tiene un requisito para llevarse a cabo:
- Tienes que asegurarte de que no se producen otros commits en la principal mientras trabajas en tu nueva rama.
Esto no siempre será posible, especialmente si trabajas en un equipo grande. Aun así, si decides fusionar tus commits con una rama principal que esté actualizada y sin commits propios, se realizará un merge fast-forward. Puedes hacerlo de dos formas distintas:
git merge <branch>
git merge --ff-only
Muchas veces, no necesitarás especificar que quieres ejecutar un merge fast-forward. Este tipo de merge se da en proyectos en solitario o con equipos pequeños. En un entorno fast-paced, se trata de un merge poco frecuente. Por ello, otros serán más habituales.
Merge Recursivo
Un merge recursivo suele ser el predeterminado, ya que aparecerá en situaciones más comunes que otros tipos de merges. Un merge recursivo es aquel en el que haces commits en una rama, pero los commits posteriores se producen también en la rama principal.
Cuando llegue el momento de fusionar, Git recurrirá a la rama para hacer su commit definitivo. Esto significa que un merge commits tendrá dos padres una vez que la completes.
Al igual que con un merge fast-forward, normalmente no necesitarás especificar un merge recursivo. Sin embargo, puedes asegurarte de que Git no elija algo como una fusión de avance rápido utilizando los siguientes comandos y banderas:
git merge --no-ff
git merge -s recursive <branch1> <branch2>
La segunda línea utiliza la opción de estrategia -s y la denominación explícita para llevar a cabo una fusión. A diferencia de una fusión fast-forward , una fusión recursiva crea una confirmación de fusión específica. Para las fusiones bidireccionales, una estrategia recursiva es sólida y funciona bien.
Ours and Theirs
Una situación común durante el desarrollo es aquella en la que creas una nueva función dentro de tu proyecto que finalmente no obtendrá luz verde. En muchos casos, tendrás mucho código que fusionar que también es codependiente. Un merge «ours» es la mejor forma de resolver estos conflictos.
Este tipo de merge puede manejar tantas ramas como necesites y funciona ignorando todos los cambios en esas otras ramas. Es ideal si deseas hacer una limpieza cuando se trata de características obsoletas o desarrollos no deseados. Aquí está el comando que necesitas:
git merge -s ours <branch1> <branch2>Un merge «ours» significa esencialmente que la rama actual contiene el código de jure. Esto enlaza con los merges «theirs», que tratan la otra rama como correcta. Sin embargo, aquí necesitas pasar otra opción de estrategia:
git merge -X theirs <branch2>
Utilizar los merges «ours» y «theirs» puede ser confuso, pero en general es seguro ceñirse a los casos de uso típicos (el de mantener todo en la rama actual y descartar el resto).
Octopus
Manejar múltiples cabezas — es decir, fusionar más de una rama en otra — puede ser un escenario complicado para un merge git. Se podría decir que necesitas más de dos manos para resolver los conflictos. Esto es perfecto para un merge octopus.
Los merges octopus son como el polo opuesto de los merges ours and theirs. El caso de uso típico es cuando quieres incluir varios commits de características similares y fusionarlos en uno solo. Aquí tienes cómo pasarlo:
git merge -s octopus <branch1> <branch2>
Sin embargo, Git rechazará un merge octopus si tienes que hacer una resolución manual más adelante. Para las resoluciones automáticas, será un merge octopus por defecto si necesitas fusionar varias ramas en una.
Resolve
Una de las formas más seguras de fusionar commits, un merge resolve es genial si tienes una situación que implica fusiones entrecruzadas. También es un método de resolución rápido de implementar. También puedes utilizarlo para historias de merge más complejas — pero sólo las que tengan dos cabezas.
git merge -s resolve <branch1> <branch2>
Dado que un merge resolve utiliza un algoritmo de tres vías para trabajar tanto con tu rama actual como con aquella de la que estás tirando, puede que no sea tan flexible como otros métodos de merge. Sin embargo, para el trabajo que necesitas, el merge resolve es casi perfecto.
Subtree
Este compañero del merge recursivo puede confundirte. Intentaremos explicarlo con un ejemplo claro:
- Primero, considera dos árboles diferentes — X e Y. A menudo serán dos repos.
- Quieres fusionar ambos árboles sólo en uno.
- Si el árbol Y se corresponde con uno de los subárboles de X, el árbol Y se modifica para que coincida con la estructura de X.
Esto significa que un merge subtree es fantástico si quieres combinar varios repos en un artículo definitivo. También realizará los cambios necesarios en el árbol «antepasado» común de ambas ramas.
git merge -s subtree <branch1> <branch2>
En resumen, un merge subtree es lo que necesitas para combinar dos repositorios. De hecho, puede que te cueste entender qué estrategia merge es la adecuada para ti. Más adelante, discutiremos algunas herramientas que podrían ayudarte.
Antes de esto, hay algunos conflictos de merge avanzados que debes saber cómo resolver.
Cómo Resolver los Conflictos Merge Git Más Complejos
Fusionar ramas en Git es más bien gestionar conflictos y resolverlos. Cuanto mayor sea el tamaño de tu equipo y de tu proyecto, mayor será la probabilidad de que surjan conflictos. Algunos de ellos pueden ser complejos y difíciles de resolver.
Dado que los conflictos pueden devorar tiempo, dinero y recursos, tienes que averiguar cómo cortarlos de raíz rápidamente. En la mayoría de los casos, dos desarrolladores trabajan en la misma suite de código y ambos deciden hacer commit.
Esto puede significar que no puedas iniciar el merge debido a cambios pendientes o que se produzca un fallo durante el merge que requiera intervención manual. Una vez que tu directorio de trabajo esté ‘limpio’ puedes empezar. Muchas veces, Git te notificará un conflicto una vez que comiences una fusión:
Sin embargo, para obtener más información, puedes ejecutar un git status y ver los detalles:
A partir de aquí, puedes empezar a trabajar en los distintos archivos que causan el conflicto. Algunas de las herramientas y técnicas que discutiremos a continuación te ayudarán.
Abortar y Reiniciar Merges
A veces, necesitas detener un merge por completo y empezar de cero. De hecho, los dos comandos que mencionamos se adaptan a situaciones en las que aún no sabes qué hacer con un conflicto.
Puedes optar por abortar o reiniciar un merge en curso con los siguientes comandos:
git merge --abort
git reset
Ambos comandos son similares, pero se utilizan en circunstancias diferentes. Por ejemplo, abortar un merge simplemente revertirá la rama a su estado previo a la fusión. En algunos casos, esto no funcionará. Por ejemplo, si tu directorio de trabajo contiene cambios no confirmados y no guardados(unstashed), no podrás ejecutar una cancelación.
Sin embargo, anular un merge significa que reviertes los archivos a un estado «bueno» conocido. Esto último es algo a tener en cuenta si Git falla al iniciar el merge. Ten en cuenta que este comando borrará cualquier cambio que no hagas commit, lo que significa que éste es un acto más intencionado que requiere cuidado.
Comprobación de Conflictos
La mayoría de los conflictos de merge serán fáciles de determinar y resolver. Sin embargo, en algunos casos, puede que tengas que profundizar más para averiguar por qué se produce un conflicto y cómo empezar a solucionarlo.
Puedes obtener más contexto después de una git merge utilizando una comprobación:
git checkout --conflict=diff3 <filename>
Esta opción utiliza la navegación típica que proporciona una comprobación y crea una comparación entre los dos archivos que muestra el conflicto de merge:
En un sentido técnico, esto comprobará de nuevo el archivo y sustituirá los marcadores de conflicto. Podrías hacer esto varias veces a lo largo de una resolución. Aquí, si pasas el argumento diff3 , te dará la versión base y las alternativas en versiones «ours» y «theirs».
Ten en cuenta que la opción de argumento por defecto es merge, que no tienes que especificar a menos que cambies el estilo de fusión de conflictos fuera del predeterminado.
Ignorar el Espacio Negativo
El espacio negativo y su uso es un punto de discusión habitual. Algunos lenguajes de programación utilizarán diferentes tipos de espaciado, e incluso los desarrolladores individuales utilizarán diferentes formatos.
Espacios frente a tabulaciones es una batalla en la que no vamos a entrar. Sin embargo, si tienes situaciones en las que el formato cambia de uno a otro dependiendo del archivo y del código, podrías encontrarte con este problema merge de Git.
Sabrás que el merge falla porque habrá líneas eliminadas y añadidas cuando mires el conflicto:
Esto se debe a que Git mira esas líneas y considera que el espacio negativo es un cambio. Sin embargo, puedes añadir argumentos específicos al comando git merge que pasarán por alto el espacio negativo en los archivos pertinentes:
git merge -Xignore-all-space
git merge -Xignore-space-change
Aunque estos dos argumentos parecen similares, tienen una diferencia única. Si decides ignorar todo el espacio negativo, Git lo hará. Es un enfoque de brocha gorda, pero en cambio, -Xignore-space-change sólo contará como equivalentes las secuencias de uno o más caracteres espaciados en negativo. Como tal, ignorará los espacios simples al final de las líneas.
Para mayor seguridad, también puedes revisar el merge utilizando el comando --no-commit, para comprobar que ignora y cuenta los espacios negativos de la forma correcta.
Merge Logs
El registro es crucial para casi todos los programas que pasan datos. En el caso de Git, puedes utilizar el registro para averiguar más detalles sobre un conflicto merge. Puedes acceder a esta información utilizando git log:
Es esencialmente una estación de volcado de archivos de texto para cada acción dentro de un repositorio. Sin embargo, puedes añadir más argumentos para refinar la vista y ver sólo los commits que desees:
git log --oneline --left-right <branch1>...<branch2>
Esto utiliza un ‘Triple Dot’ para proporcionar una lista de commits implicados en dos ramas durante un merge. Filtrará todos los commits que comparten ambas ramas, lo que dejará una selección de commits para investigar más a fondo.
También puedes utilizar git log --oneline --left-right --merge para mostrar sólo los commits a ambos lados de un merge que «toquen» un archivo en conflicto. La opción -p te mostrará los cambios exactos de un ‘diff’ concreto, aunque ten en cuenta que esto sólo es para los commits no fusionados. Existe una solución para esto, que veremos a continuación.
Uso del Formato Diff Combinado para Investigar un Conflicto Merge en Git
Puedes llevar la vista que obtienes con git log más allá para investigar conflictos merge. En circunstancias típicas, Git fusionará código y listará todo lo que tenga éxito. Esto te dejará sólo las líneas conflictivas, y puedes verlas utilizando el comando git diff:
Este formato de «combined diff» añade dos columnas extra de información. La primera te dice si una línea es diferente entre tu rama («ours») y la copia de trabajo; la segunda te da la misma información para la rama «theirs».
En cuanto a los signos, un signo más indica si una línea se añade a la copia de trabajo pero no en ese lado concreto del merge, y un signo menos indica si la línea se elimina.
Ten en cuenta que también puedes ver este formato de diff combinado dentro del registro de Git utilizando un par de comandos:
git show
git log --cc -p
El primero es un comando que utilizas en un merge commit para ver su historial. El segundo comando utiliza la funcionalidad de -p para mostrar los cambios de un non-merge commit junto al formato diff combinado.
Cómo Deshacer un Merge de Git
Los errores pueden ocurrir, y puedes llevar a cabo merges sobre los que necesites volver atrás. En algunos casos, puedes simplemente modificar el commit más reciente utilizando git commit --amend. Esto abrirá el editor para permitirte modificar el último mensaje commit.
Aunque los conflictos merge más complejos y los cambios resultantes se pueden revertir, puede resultar difícil porque los commits suelen ser permanentes.
Por tanto, hay muchos pasos a seguir:
- En primer lugar, tienes que revisar los commits y encontrar referencias a los merges que necesitas.
- Después, comprueba las ramas para revisar los historiales de commits.
- Una vez que conozcas las ramas y commits que necesitas, existen comandos Git específicos en función de la acción que desees realizar.
Veámoslos con más detalle y empecemos por el proceso de revisión. A partir de ahí, podemos mostrarte una forma rápida de deshacer un merge de Git, y luego veremos comandos específicos para casos de uso más avanzados.
Revisar Commits
El comando git log --oneline es estupendo si quieres ver los ID de revisión y el mensaje commit relativos a la rama actual:
El comando git log --branches=* te mostrará la misma información pero para todas las ramas. En cualquier caso, puedes utilizar los ID de referencia junto a un git checkout para crear un estado ‘HEAD desvinculado'(‘detached HEAD’). Esto significa que no trabajarás en ninguna rama desde un punto de vista técnico, y una vez que vuelvas a una rama establecida, dejarás ‘huérfanos’ los cambios.
Como tal, puedes utilizar la comprobación casi como una caja de arena sin riesgos. Sin embargo, si quieres conservar los cambios, puedes hacer checkout de la rama y darle un nuevo nombre utilizando git checkout -b <branch-name>. Esta es una forma sólida de deshacer un merge de Git, pero hay formas más matizadas de hacerlo para casos de uso avanzados.
Usar git reset
Muchos de tus conflictos de fusión pueden ocurrir en un repositorio local. En estos casos, git reset es el comando que necesitas. Sin embargo, este comando tiene más parámetros y argumentos en los que hay que profundizar. A continuación te explicamos cómo utilizar el comando en la práctica:
git reset --hard <reference>
La primera parte – git reset --hard – consta de tres pasos:
- Mueve la rama de referencia a su ubicación anterior al merge commit.
- El hard reset hace que el «índice» (es decir, la siguiente instantánea de commit propuesta) se parezca a la rama de referencia.
- Hace que el directorio de trabajo se parezca al índice.
Una vez que invocas este comando, el historial de commits elimina los commit posteriores y restablece el historial al ID de referencia. Es una forma limpia de deshacer un merge de Git, pero no es adecuada para todos los casos.
Por ejemplo, provocará un error si intentas enviar un commit de reinicio local a un repositorio remoto que contenga ese commit. En este caso, hay otro comando que puedes utilizar.
Usar git revert
Aunque tanto git reset como git revert parecen similares, hay algunas diferencias importantes. En los ejemplos hasta ahora, el proceso de deshacer implica mover los punteros de referencia y HEAD a un commit específico. Es parecido a barajar las cartas para crear un nuevo orden.
En cambio, git revert crea un nuevo commit basado en revertir cambios, luego actualiza los punteros de referencia y convierte la rama en la nueva «punta» También es la razón por la que deberías utilizar este comando para conflictos merge de repos remotos.
Puedes utilizar git revert <reference> para deshacer un merge de Git. Ten en cuenta que siempre tienes que especificar una referencia de commit, o el comando no se ejecutará. También puedes pasar HEAD al comando para revertir al último commit.
Sin embargo, puedes dar a Git una mayor claridad sobre lo que quieres hacer:
git revert -m 1 <reference>
Cuando invoques el merge, el nuevo commit tendrá dos «padres» Uno se refiere a la referencia que especifiques, y el otro es la punta de la rama que quieres fusionar. En este caso, -m 1 le dice a Git que mantenga el primer padre — es decir, la referencia especificada — como la «línea principal»
La opción por defecto para git revert es -e o --edit. Esto abrirá el editor para modificar el mensaje commit antes de revertir. Sin embargo, también puedes pasar --no-edit, que no abrirá el editor.
También puedes pasar -n o --no-commit. Esto indica a git revert que no cree un nuevo commit, sino que «invierta» los cambios y los añada al índice de preparación y al directorio de trabajo.
La Diferencia Entre Hacer Merge y Rebase en Git
En lugar de utilizar el comando git merge, también puedes utilizar git rebase. También es una forma de integrar los cambios en un directorio, pero con una diferencia:
- Una fusión a tres es la predeterminada cuando utilizas
git merge. Combina instantáneas de dos ramas actuales y las fusiona con un ancestro común de ambas para crear un nuevo commit. - Rebasar implica tomar un cambio parcheado de una rama divergente y aplicarlo a otra, sin necesidad del ancestro. Esto significa que no habrá un nuevo commit.
Para utilizar este comando, comprueba la rama a la que quieres hacer el rebase. A partir de ahí, puedes utilizar el siguiente comando:
git rebase -i <reference>
En muchas situaciones, tu referencia será tu rama principal. La opción -i inicia el «rebase interactivo» Esto te da la oportunidad de alterar los commits a medida que se mueven. Puedes utilizarlo para limpiar el historial de commits, que es una de las grandes ventajas de utilizar git rebase.
Al ejecutar el comando se mostrará en el editor una lista de posibles commits a mover. Esto te da un alcance completo para cambiar el aspecto del historial de commits. También puedes fusionar commits si cambias el comando pick por fixup. Una vez que guardes tus cambios, Git realizará el rebase.
En general, utilizas Git merge para muchos conflictos. Sin embargo, rebasar también tiene muchas ventajas. Por ejemplo, mientras que haver merge es sencillo de usar y te permite conservar el contexto que rodea a tu historial de merges, rebasar puede ser más limpio, ya que puedes simplificar tu historial de commits en uno solo.
A pesar de ello, tienes que tener más cuidado con rebase, ya que el potencial de errores es enorme. Además, no deberías utilizar esta técnica en ramas públicas, ya que rebase sólo afectará a tu repositorio. Para solucionar los problemas resultantes, necesitarás hacer aún más merges y verás múltiples commits.
Herramientas que Te Ayudan a Gestionar Mejor un Merge de Git
Dadas las complejidades que rodean a los conflictos merge de Git, puede que quieras que te echen una mano. Existen un montón de herramientas disponibles para ayudarte a llevar a cabo un merge con éxito, y si utilizas Intellij IDEA, tienes un método incorporado utilizando el menú Branch:
VSCode también incluye una funcionalidad similar en su interfaz de usuario (UI). Los antiguos usuarios de Atom descubrirán que Microsoft ha continuado aquí con su fantástica integración de Git, completa con la capacidad de conectarse a GitHub sin más extensiones o add-ons.
También dispones de más opciones mediante la Paleta de Comandos. Esto ocurre incluso en los editores que se basan en el framework de código abierto de VSCode, como Onivim2:
La ventaja aquí, como en el caso de todas las herramientas de esta lista, es que no necesitas la línea de comandos para realizar merges. Normalmente tienes que seleccionar una rama de origen y otra de destino en un menú desplegable, y luego dejar que el editor lleve a cabo el merge. Aun así, no tienes que adoptar un enfoque de no intervención. Puedes revisar los cambios después, y luego hacer el commit que necesites.
Un editor que ofrece una interfaz gráfica de usuario (GUI) independiente para trabajar con Git es Sublime Text. Si utilizas este editor, Sublime Merge podría ser un complemento ideal para tu flujo de trabajo:
Independientemente del editor de código que elijas, a menudo incluirá la posibilidad de trabajar con Git sin utilizar la línea de comandos. Esto ocurre incluso con Vim y Neovim, utilizando el plugin Tim Pope’s Git Fugitive, que es fantástico y sencillo de utilizar.
Sin embargo, hay algunas herramientas de merge de terceros dedicadas que se centran exclusivamente en esta tarea.
Aplicaciones Dedicadas al Merge de Git
Por ejemplo, Mergify es unaforma de fusionar código a nivel empresarial que se integra en tu canal y flujo de trabajo de integración continua/entrega continua (CI/CD):
Algunas de sus funciones te ayudan a automatizar la actualización de tus pull requests antes del merge, a reordenarlas en función de su prioridad y también a procesarlas por lotes. Para una solución de código abierto, Meld puede ser valiosa:
Su versión estable es compatible con Windows y Linux y funciona bajo licencia GPL. Te ofrece una funcionalidad básica para comparar ramas, editar tus merges y mucho más. Incluso tienes comparaciones a dos o tres bandas y soporte para otros sistemas de control de versiones como Subversion.
Resumen
Git es una herramienta esencial para colaborar y gestionar eficazmente los cambios en el código. Sin embargo, si varios desarrolladores trabajan en el mismo código, pueden surgir conflictos. Las estrategias de merge de Git te ayudarán a resolver estos conflictos, y hay muchas formas de hacerlo. Para estrategias de merge de Git más complejas, debes recurrir a tácticas avanzadas.
Esto puede ser incluso tan sencillo como ignorar el espacio negativo o rebuscar en los registros de búsqueda. Sin embargo, tampoco tienes que utilizar siempre la línea de comandos. Hay un montón de aplicaciones que te ayudarán, y tu editor de código a menudo también utilizará una interfaz integrada.
Si quieres asegurarte un alojamiento de aplicaciones de alta calidad, nosotros te ayudamos. Nuestros servicios de alojamiento de aplicaciones basados en la nube garantizan que tu aplicación full-stack esté lista para funcionar en un abrir y cerrar de ojos.
¿Cuál de estas estrategias de Git merge te sacará de un apuro? ¡Háznoslo saber en la sección de comentarios más abajo!
Deja una respuesta