Cómo resolver conflictos de Git Merge en la línea de comandos y en un editor de tres vías

Para resolver conflictos de fusión en Git, abra cada archivo que Git informa como en conflicto, decida cuál debe ser el código entre los marcadores <<<<<<<, ======= y >>>>>>>, elimine los marcadores, prepare el archivo con git add y termine con git commit (o git merge --continue). Para retroceder, ejecute git merge --abort. Esta guía recorre ese bucle en la línea de comandos, luego en un editor visual de tres vías y finaliza con los hábitos que hacen que los conflictos sean más raros y fáciles de deshacer. Para practicar las opciones que le ofrece una combinación, un cambio de base o una selección en pausa, tome la lección gratuita Continuar, omitir o cancelar una operación activa.

Los ejemplos visuales utilizan GitTree, el cliente Git que creamos para macOS, Windows y Linux. Ejecuta el Git instalado en su computadora, por lo que al hacer clic y escribir se obtiene el mismo resultado; la GitTree lista de funciones tiene una imagen más amplia.

Qué conflicto de fusión es realmente en Git

Git fusiona línea por línea usando tres versiones de cada archivo: la base (la última confirmación que comparten ambas ramas), la nuestra (su rama actual, HEAD) y la de ellos (la rama entrante, MERGE_HEAD). Si solo un lado cambió una región, Git toma ese cambio. Si ambas partes cambiaron las mismas líneas de manera diferente, Git se detiene, escribe ambas versiones en el archivo y le deja la decisión a usted.

Lo mismo puede pasar en git pull, git rebase, git cherry-pick, git revert y git stash pop. La solución es idéntica; sólo difiere la orden final. git status etiqueta cada ruta en conflicto:

• ambas modificadas: ambas ramas cambiaron las mismas líneas. Este es el caso común.
• eliminado por nosotros / eliminado por ellos: un lado eliminó el archivo y el otro lo cambió, por lo que usted conserva el archivo modificado o confirma la eliminación.
• ambos agregados: cada rama creó un archivo diferente en la misma ruta.

Cómo solucionar conflictos de fusión en la línea de comando

1. Encuentra los archivos en conflicto

Git enumera los conflictos en el momento en que se detiene la fusión y git status mantiene la lista hasta que finalice. git diff --name-only --diff-filter=U imprime solo las rutas no fusionadas.

$ git merge feature/login
Auto-merging src/auth.ts
CONFLICT (content): Merge conflict in src/auth.ts
Automatic merge failed; fix conflicts and then commit the result.

$ git status
On branch main
You have unmerged paths.

Unmerged paths:
  (use "git add <file>..." to mark resolution)
        both modified:   src/auth.ts

2. Lee los marcadores de conflicto.

Todo lo que estaba fuera de los marcadores se fusionó limpiamente. El bloque después de <<<<<<< HEAD es su rama actual, el bloque antes de >>>>>>> feature/login es el entrante y la línea ======= los separa.

export const retries = 3;
<<<<<<< HEAD
export const timeout = 45;
=======
export const timeout = 60;
>>>>>>> feature/login
export const debug = false;

A menudo, dos versiones no son suficientes para decidir. Configure el estilo de conflicto zdiff3 de Git una vez y cada conflicto también mostrará la base, después de una línea |||||||:

$ git config --global merge.conflictStyle zdiff3

<<<<<<< HEAD
export const timeout = 45;
||||||| 556e564
export const timeout = 30;
=======
export const timeout = 60;
>>>>>>> feature/login

Ahora puede ver que main aumentó el tiempo de espera de 30 a 45 y la rama de características a 60: decida qué valor necesita el producto, no qué rama gana.

3. Edite el archivo y márquelo resuelto.

Escribe el código que quieras (un lado, el otro, una mezcla o algo nuevo) y borra cada línea del marcador. Deje que Git compruebe si hay restos antes de la puesta en escena, porque un ======= perdido cometido por accidente es una clásica compilación rota.

$ git diff --check          # lists any leftover conflict markers
$ git add src/auth.ts
$ git commit                # or: git merge --continue

Si la versión de todo el archivo de una de las partes es correcta, tómela directamente. Para que Git prefiera un lado para cada fragmento en conflicto mientras se fusiona, inicie la fusión con git merge -X ours o git merge -X theirs en su lugar; Los cambios que no entran en conflicto aún provienen de ambas ramas.

$ git checkout --ours -- src/auth.ts     # keep the current branch's version
$ git checkout --theirs -- src/auth.ts   # keep the incoming version
$ git add src/auth.ts

4. Finalizar la operación

Cuando cada archivo esté preparado, continúe con lo que se detuvo: git commit (o git merge --continue), git rebase --continue, git cherry-pick --continue o git revert --continue. Una rebase puede detenerse nuevamente en una confirmación posterior; repite el bucle.

Resolver conflictos de fusión en una GUI: un solucionador de conflictos de Git de tres vías

Los marcadores están bien para un choque de dos líneas. Con una docena de conflictos en un archivo largo, una solución de conflictos GUI es más rápida y mucho más difícil de equivocar. Una buena herramienta de fusión de conflictos de Git muestra las tres versiones juntas, le permite decidir conflicto por conflicto y se niega a guardar mientras permanecen los marcadores.

En GitTree, una combinación que se detiene muestra un banner con la cantidad de conflictos y una lista de los archivos en conflicto. Abra uno y el editor tomará toda la ventana: las ramas actual y entrante una al lado de la otra en la parte superior, cada una etiquetada con su nombre de rama, y ​​Salida, el archivo tal como se guardará, debajo.

• Por conflicto: tome el lado actual, el lado entrante, ambos o ninguno, o elija líneas individuales de cada uno.
• Editar salida a mano para cualquier cosa que los botones no cubran.
• Mostrar base para ver el ancestro común (Git lo escribe cuando merge.conflictStyle es diff3 o zdiff3).
• Deshacer elección para retroceder en tus decisiones.
• Archivos eliminados: cuando una parte eliminó un archivo y la otra cambió, conserve el archivo de esa parte o confirme la eliminación.

GitTree no guardará un resultado que todavía contenga líneas de marcador. También puede abrir el archivo en su herramienta de combinación externa: VS Code, Cursor, JetBrains IDE, Beyond Compare, Meld, KDiff3, P4Merge, WinMerge, un programa personalizado o el propio merge.tool de Git. Si la herramienta se cierra sin resolver el archivo, el archivo permanece en conflicto.

Predecir conflictos de fusión antes de fusionar

Desde Git 2.38, git merge-tree --write-tree realiza una fusión en la memoria sin leer ni escribir su árbol de trabajo o índice, y sin realizar una confirmación. Con --name-only enumera los archivos que entrarían en conflicto; el estado de salida es 1 cuando hay conflictos y 0 cuando la fusión sería limpia.

$ git fetch
$ git merge-tree --write-tree --name-only HEAD origin/main
0d708adc4a836d088802870278cb1f3daf06355f
src/auth.ts

Auto-merging src/auth.ts
CONFLICT (content): Merge conflict in src/auth.ts

GitTree ejecuta esta vista previa por usted: el cuadro de diálogo de combinación muestra el resultado previsto antes de que usted confirme. Después de cada recuperación, también compara su rama con su rama ascendente y base (principal o maestra a menos que configure otra) y muestra una advertencia junto al nombre de la rama, como "Entraría en conflicto con la principal en 2 archivos". Una segunda pista marca los archivos que está cambiando y que otras ramas recuperadas y no fusionadas también cambian.

Ambas comprobaciones utilizan sólo lo que ya ha obtenido: no se recupera, fusiona ni cambia nada para calcularlos, y nada sale de su computadora. Cualquiera de los dos se puede desactivar en Preferencias.

Reutilizar resoluciones de conflictos con git rerere

Rerere significa "reutilizar resolución grabada". Cuando está activado, Git registra cada conflicto y cómo lo resolvió. Cuando vuelve el mismo conflicto, digamos en un rebase repetido de una rama de larga duración o en una fusión que rehace, Git escribe su resolución anterior en el archivo.

$ git config --global rerere.enabled true
$ git rerere forget src/auth.ts   # drop a recorded resolution that was wrong

Git deja el resultado reutilizado sin preparar para su revisión a menos que se establezca rerere.autoUpdate. En GitTree, la configuración del repositorio tiene modificadores Reutilizar resoluciones grabadas (rerere) y Evaluar resoluciones reutilizadas para esas opciones de Git; la vista de conflicto etiqueta una resolución reutilizada y Olvidar resolución elimina una incorrecta.

Cómo abortar o cancelar una fusión en Git

Para cancelar una combinación que se detuvo debido a conflictos, ejecute git merge --abort. Un rebase, una selección selectiva o una reversión tienen su propio aborto:

$ git merge --abort
$ git rebase --abort
$ git cherry-pick --abort
$ git revert --abort

La propia documentación de Git advierte que git merge --abort no siempre puede reconstruir los cambios no confirmados que tenía cuando comenzó la fusión. Confirme o guarde antes de fusionarse, y la cancelación solo tendrá trabajo confirmado para restaurar.

En GitTree, Abort Merge (o Abort Rebase, Cherry-Pick, Revert) explica primero que Git restaura la rama, el índice y la copia de trabajo anteriores a la operación y elimina las resoluciones realizadas hasta el momento. GitTree guarda todo lo que se elimina al cancelar, preparado o no, en instantáneas de recuperación, para que Deshacer pueda recuperarlo.

Cómo deshacer una fusión después de haberla cometido

Lo que debe hacer depende de si ha impulsado la combinación:

# Not pushed yet, right after the merge:
$ git reset --hard ORIG_HEAD     # also discards uncommitted changes
$ git reset --merge ORIG_HEAD    # keeps uncommitted changes

# Already pushed:
$ git revert -m 1 <merge-commit> # a new commit that reverses it

Una combinación guarda el consejo anterior de su rama en ORIG_HEAD, por lo que restablecerla elimina la combinación, a menos que un reinicio o rebase posterior mueva ORIG_HEAD. Una vez que otros tengan la fusión, revierta. Revertir una fusión le dice a Git que nunca querrás esos cambios: fusionar esa rama nuevamente no los recuperará a menos que reviertas la reversión.

En GitTree, seleccione el primer padre de la fusión (la confirmación en la que estaba su rama antes) en el gráfico y elija un restablecimiento parcial, mixto o completo en el menú de confirmación, cada uno etiquetado con lo que conserva. GitTree toma instantáneas de 19 tipos de operaciones antes de ejecutarse, incluidos los reinicios, por lo que Deshacer puede revertir el reinicio y la vista de registro recupera estados más antiguos. La guía para deshacer un reinicio, rebase o confirmación cubre la recuperación en profundidad.

Cómo prevenir la mayoría de los conflictos de fusión

• Mantenga las ramas pequeñas y de corta duración. Cuanto más divergen dos ramas, más líneas se tocan.
• Traiga la rama base con frecuencia, ni una vez al final.
• Separe el formato de la lógica. Acuerde un formateador y formatee todo el archivo por sí solo.
• Regenere los archivos de bloqueo en lugar de fusionarlos manualmente. Tome cualquier lado y luego ejecute su administrador de paquetes nuevamente.
• Active zdiff3 y rerere una vez. Dos comandos, beneficio duradero.
• Confirmar o guardar antes de la integración, para que cada cancelación y deshacer sea exacta.

¿Quieres practicar primero en un repositorio seguro? La lección gratuita Fusionar ramas divergentes y verificar ambos padres en los tutoriales de Git explica una fusión real. ¿Sigues comparando el terminal con una GUI? Git GUI vs línea de comando compara ambos honestamente.

GitTree tiene un plan gratuito que cubre todas las funciones de Git, incluidos los repositorios privados, y Nour, el asistente de IA, viene con GitTree Pro (consulte precios); necesita Git 2.39 o más reciente y una cuenta GitTree para iniciar sesión. Consíguelo para macOS, Windows o Linux, o consulta todos los instaladores en la GitTree página de descarga. El Ubuntu 22.04, actualice Git primero. ¿Atrapado en un conflicto persistente? Pregunte al soporte técnico de GitTree.