En la lección anterior, cada vez que Git creó un commit de fusión nos dijo lo mismo: Merge made by the 'ort' strategy. Pasamos de largo, pero esa palabra esconde una parte importante de cómo funciona Git.

Una estrategia de fusión es el algoritmo que Git emplea para combinar dos (o más) líneas de trabajo. No hay una sola: Git trae varias, elige una por defecto según el caso, y te permite imponer otra. Además, cada estrategia admite opciones que modifican su comportamiento en detalles concretos, como qué hacer ante un conflicto o si ignorar cambios de espacios en blanco.

En la práctica, el 95 % de las fusiones que harás usarán la estrategia por defecto sin que tengas que pensar en ello. Pero el 5 % restante —una fusión con cientos de conflictos triviales, una rama abandonada que hay que "cerrar" formalmente, una funcionalidad hecha con veinte commits caóticos que no quieres meter en main— es exactamente donde conocer las alternativas ahorra horas.

Esta lección cubre también una decisión que va más allá del algoritmo: qué forma de integrar elegir según el historial que quieras acabar teniendo. Fusión normal, --no-ff, squash… o rebase, que veremos en el módulo 5 pero que conviene situar ya en el mapa.

1. Qué es exactamente una estrategia de fusión
2. ort: la estrategia por defecto
3. resolve: la veterana
4. octopus: varias ramas de una vez
5. La estrategia ours: descartar el contenido, conservar la historia
6. subtree: fusionar proyectos anidados
7. Opciones de estrategia con -X
8. La trampa: estrategia ours frente a opción -X ours
9. El squash merge
10. --no-commit: revisar antes de sellar
11. Tabla de decisión: qué forma de integrar elegir

Cuando git merge tiene que combinar de verdad —es decir, cuando no es un fast-forward—, necesita responder a una pregunta por cada fichero y por cada línea: dado lo que había en el ancestro común y lo que hay en cada lado, ¿qué pongo aquí?

El conjunto de reglas que responde a esa pregunta es la estrategia. Se elige con -s o --strategy:

Y sus opciones internas con -X o --strategy-option:

Las dos se pueden combinar, y -X se puede repetir:

Comparemos primero todas las estrategias disponibles, y después veamos cada una:

ort significa Ostensibly Recursive's Twin ("el gemelo aparente de recursive"), un nombre con sentido del humor que delata su origen: es una reescritura desde cero de la estrategia recursive, diseñada para dar los mismos resultados pero mucho más rápido y con menos casos raros.

Es la estrategia por defecto desde Git 2.34 (noviembre de 2021). Antes lo era recursive. Hoy, si escribes -s recursive, Git usa ort de todas formas.

Lo que hace, resumido:

1. Calcula el ancestro común de las dos ramas.
2. Hace la fusión a tres bandas fichero a fichero y línea a línea, con la tabla de reglas que vimos en la lección 03-03.
3. Detecta renombrados: si en una rama moviste estilos.css a css/estilos.css y en la otra lo modificaste, aplica los cambios al fichero en su nueva ubicación en lugar de darte un conflicto absurdo.
4. Si hay varios ancestros comunes, los fusiona entre sí recursivamente hasta obtener uno virtual, y usa ese como base.

Ese punto 4 es el que da nombre a la familia y merece un momento. Puede haber más de un ancestro común cuando el historial tiene fusiones cruzadas:

Aquí, tanto D como E son ancestros comunes de rama-1 y rama-2, y ninguno es antepasado del otro. Una estrategia simple tendría que elegir uno arbitrariamente, con el riesgo de producir conflictos falsos. ort los fusiona entre sí para construir una base virtual que combine la información de ambos.

No necesitas provocar esta situación para trabajar: solo saber que existe y que Git la resuelve solo. Es la razón de que las fusiones en historiales complejos funcionen sorprendentemente bien.

resolve es la estrategia clásica: fusión a tres bandas con un único ancestro común, elegido si hay varios. No hace recursión y detecta renombrados de forma mucho más limitada.

¿Cuándo usarla? Prácticamente nunca. Su nicho es el caso raro en el que ort produce un resultado que no te convence en un historial con fusiones cruzadas y quieres probar una base distinta. Es más un recurso de diagnóstico que una herramienta de trabajo.

Está en el temario porque la verás mencionada en documentación antigua y porque conocerla ayuda a entender por qué ort hace lo que hace.

git merge no se limita a un argumento. Puedes nombrar varias ramas:

Cuando hay tres o más, Git cambia automáticamente a la estrategia octopus, que crea un único commit de fusión con tantos padres como ramas más una.

Imaginemos que el equipo ha acumulado tres correcciones diminutas e independientes, cada una en su rama:

Cuatro padres. El primero es main y los otros tres, las puntas de las ramas fusionadas.

La limitación crucial de octopus: se niega a trabajar si hay cualquier conflicto.

No hay resolución posible, no hay marcadores en los ficheros, no hay nada que arreglar: la operación se aborta entera. La razón es de diseño: resolver conflictos entre cuatro versiones simultáneas sería inmanejable para una persona.

Por eso su uso realista es muy concreto: integrar de golpe varias ramas que no se pisan entre sí. Si alguna conflictúa, tendrás que fusionarlas de una en una. En el día a día de un equipo pequeño la verás poco; en proyectos con muchísimas aportaciones independientes (el núcleo de Linux es el ejemplo canónico, y no por casualidad, ya que fue el proyecto para el que se escribió Git) tiene todo el sentido.

Esta es la estrategia más peculiar del conjunto y la que más se malinterpreta.

Lo que hace: crea un commit de fusión con los dos padres normales, pero el árbol resultante es exactamente el de la rama actual. El contenido de la otra rama se descarta por completo.

Suena absurdo. ¿Para qué fusionar algo que vas a tirar? Para registrar en el historial que esa rama ya está considerada, sin traer su código.

El caso de uso real en el proyecto de Ana: el equipo abrió hace un mes la rama experimento/almacenamiento-indexeddb para probar un sistema de almacenamiento distinto. El experimento se descartó —al final se quedaron con localStorage—, pero la rama sigue ahí y de vez en cuando alguien pregunta si hay que integrarla.

Fíjate en que no lista ningún fichero cambiado: no ha cambiado nada.

Cero diferencias respecto al commit anterior de main. El código es idéntico. Pero:

La rama consta como fusionada, con lo que aparecerá en las listas de ramas que se pueden borrar sin perder nada (lección 03-06), dejará de salir en los avisos de "ramas pendientes de integrar", y el historial contiene una explicación permanente de por qué se descartó.

Otro uso clásico: cuando dos ramas han divergido tanto que reconciliarlas a mano es inviable y quieres que gane una entera, dejando constancia de la decisión.

Advertencia importante: -s ours descarta todo el contenido de la otra rama sin preguntar y sin avisar. No hay conflictos, no hay revisión, no hay marcha atrás automática. Es una decisión deliberada, no un atajo para salir de una fusión difícil. Y no la confundas con -X ours, que es algo completamente distinto y que veremos en el apartado 8.

subtree es una variante de ort para el caso en que una rama contiene un proyecto que en la otra vive dentro de un subdirectorio.

Supón que el equipo desarrolla aparte una pequeña biblioteca de componentes, en su propio repositorio, y que en gestor-tareas esa biblioteca vive en vendor/componentes/. Al fusionar la rama de la biblioteca, una estrategia normal intentaría casar sus ficheros con la raíz del proyecto y produciría un desastre. subtree detecta el desplazamiento de rutas y aplica los cambios donde corresponde.

También se puede indicar el prefijo a mano, que es más fiable que dejar que Git lo adivine:

Este mecanismo es la base del comando git subtree, una de las dos formas de anidar repositorios. La otra son los submódulos, que tienen lección propia en el módulo 6. Por ahora basta con que sepas que la estrategia existe y para qué escenario está pensada.

Las opciones no cambian el algoritmo: lo ajustan. Estas son las que valen la pena:

Este es el que más veces te va a salvar. Situación real: Bruno ha configurado su editor para reindentar automáticamente al guardar, y ha reindentado app.js entero en su rama. Ana ha modificado tres líneas del mismo fichero en la suya.

Ochenta conflictos, y ninguno real: son todos diferencias de sangrado. Solución:

Los ochenta conflictos falsos desaparecen y quedan solo los cambios reales.

Dos matices importantes:

• Estas opciones afectan a cómo se comparan las líneas, no al resultado escrito. El fichero final conserva el sangrado de una de las versiones (la de ours en los tramos ambiguos), así que revisa el resultado.
• Si el problema del sangrado es recurrente en el equipo, la solución de fondo no es -X sino .gitattributes y un formateador automático compartido. Es el tema de la lección 08-04.

Un ejemplo típico: un fichero generado automáticamente (un bundle.js, un fichero de bloqueo de dependencias) que conflictúa siempre y en el que la versión de la rama entrante es la correcta:

Es cómodo, pero usa -X ours/-X theirs con la cabeza: resuelven todos los conflictos del mismo lado, sin distinguir cuáles eran importantes. Si el resultado te importa, es mejor resolver a mano (lección 03-05) o limitar el atajo a los ficheros concretos que lo merecen, que también se puede hacer y veremos allí.

Se escriben casi igual y hacen cosas radicalmente distintas. Es una de las confusiones más caras de Git, así que vamos a dejarla clavada.

Un ejemplo concreto. La rama funcionalidad/filtro-pendientes aporta dos cosas: un fichero nuevo filtros.js (que no conflictúa con nada) y una modificación de la línea 12 de app.js (que sí conflictúa con un cambio de Ana).

Resultado: no aparece filtros.js y la línea 12 es la de Ana. Se ha descartado todo, incluso lo que no molestaba a nadie.

Resultado: filtros.js sí aparece, porque no había conflicto con él, y la línea 12 es la de Ana, porque ahí sí lo había. Fusión real con desempate automático.

Regla mnemotécnica: -s es la estrategia, y una estrategia decide todo. -X es una opción, y una opción solo decide los empates.

Y una precisión sobre el vocabulario, porque también confunde: en una fusión, ours es siempre la rama en la que estás y theirs la que has nombrado en el comando. Suena obvio, pero durante un rebase los papeles se invierten respecto a lo que uno esperaría, y ese es uno de los motivos por los que el rebase merece su propia lección (05-01).

Cambiamos de tercio. El squash merge no es una estrategia: es una forma distinta de integrar, y en muchos equipos es la más usada de todas.

Situación en el proyecto: Bruno ha desarrollado la exportación del listado a CSV en la rama funcionalidad/exportar-csv. Ha funcionado, pero el historial de la rama es un desastre:

Seis commits, cuatro de los cuales no aportan nada a nadie que lea el historial dentro de seis meses. Bruno no quiere meter eso en main.

Lee bien: Squash commit -- not updating HEAD. Git ha calculado el resultado de la fusión y lo ha dejado en el área de preparación, pero no ha confirmado nada.

Ahora Bruno escribe un mensaje decente y confirma:

La diferencia esencial:

Ese "no queda registrada la relación" tiene una consecuencia práctica muy concreta. Después de un squash, main no es descendiente de funcionalidad/exportar-csv:

La rama de Bruno no aparece, aunque su contenido esté íntegramente en main. Si intentas borrarla:

Git no miente: desde el punto de vista del grafo, esos seis commits no están en main. Habrá que borrarla con -D sabiendo lo que se hace. Volveremos sobre esto en la lección 03-06.

A favor:

• main tiene un commit por funcionalidad, limpio y con un mensaje escrito con calma.
• El desorden de la rama de trabajo (los wip, los "ahora sí") no contamina el proyecto.
• git bisect (lección 06-02) funciona mejor: cada commit de main es un estado completo y funcional.
• Es el modelo por defecto del botón "Squash and merge" de las plataformas de alojamiento, y por tanto el más extendido hoy en equipos que trabajan con propuestas de cambio.

En contra:

• Se pierde el detalle del desarrollo. Si la funcionalidad son 40 commits bien escritos, aplastarlos es destruir información útil.
• Se pierde la autoría individual: un commit hecho con aportaciones de tres personas queda a nombre de quien lo confirma.
• Las ramas hay que borrarlas con -D, sin la red de seguridad de -d.
• Si sigues trabajando en la rama después del squash y vuelves a fusionar, Git no sabe que aquello ya estaba integrado y puede reproducir conflictos ya resueltos.

Regla práctica: squash para ramas cortas de una sola persona con commits desordenados; fusión con --no-ff para funcionalidades grandes con un historial que merece conservarse.

git merge --no-commit hace la fusión de verdad pero se detiene justo antes de crear el commit:

En este punto puedes:

Y después, confirmar o abortar:

La diferencia con --squash es fundamental y a menudo se confunde, porque las dos "paran antes de confirmar":

Ese fichero MERGE_HEAD es el detalle técnico que lo explica todo: con --no-commit hay una fusión en curso que Git recuerda, y por eso el commit resultante tendrá dos padres y --abort funciona. Con --squash no hay ninguna fusión en curso: solo hay unos cambios preparados en el índice.

Usos habituales de --no-commit:

• Ejecutar la batería de pruebas sobre el resultado combinado antes de dejarlo en main.
• Revisar una fusión grande fichero a fichero.
• Ajustar detalles menores (un import duplicado, un espacio) y meterlos en el propio commit de fusión.

Recopilamos todo lo visto en este módulo, más el rebase que llega en el módulo 5, en una única tabla de decisión:

Sobre la última fila, lo justo para situarla: el rebase no fusiona, sino que reescribe los commits de tu rama como si los hubieras hecho a partir del estado actual de main. El resultado es un historial lineal sin nodos de fusión, a cambio de que los commits cambian de hash y por tanto son commits nuevos. Eso tiene implicaciones serias cuando el trabajo ya se ha compartido, y por eso tiene lección propia. Aquí solo necesitas saber que es la tercera alternativa junto a la fusión y el squash.

Si estás empezando y no tienes una política de equipo que seguir:

1. Fusión normal para todo, dejando que Git decida entre fast-forward y tres bandas.
2. --no-ff cuando integres algo que quieras poder identificar como una unidad en el futuro.
3. --squash cuando la rama sea tuya, corta y desordenada.
4. No toques -s ni -X hasta que un problema concreto te pida una de esas opciones.

Y sobre todo, que el equipo entero haga lo mismo. Un historial coherente vale más que un historial óptimo pero irregular. Las convenciones de flujo con nombre —Git Flow, GitHub Flow, Trunk Based Development— son precisamente eso: paquetes de decisiones ya tomadas. Tienen su sitio en el módulo 7.

Error 1: confundir -s ours con -X ours. Es el error más caro de esta lección. -s ours descarta silenciosamente todo el trabajo de la otra rama, incluidos los ficheros que no daban ningún problema. Si lo que querías era desempatar conflictos, la opción es -X ours. Si alguna vez dudas, git diff HEAD~1 HEAD después de la fusión te dirá enseguida si has traído algo o nada.

Error 2: usar -X theirs como atajo universal. Resuelve todos los conflictos del mismo lado, incluidos aquellos en los que tu versión era la correcta. Se pierde trabajo sin que nada avise. Reserva estas opciones para conflictos que sabes que son irrelevantes.

Error 3: creer que --squash fusiona. No lo hace: prepara los cambios y se va. Si olvidas el git commit posterior, te quedas con un montón de cambios preparados en main y una sensación rara de que "la fusión no ha funcionado". Y aunque confirmes, la rama seguirá figurando como no fusionada.

Error 4: hacer squash de una rama y seguir trabajando en ella. Como el commit resultante no tiene relación con los originales, la siguiente fusión de esa rama volverá a traer todo lo anterior y reproducirá conflictos ya resueltos. Tras un squash, la rama se cierra: se borra y se abre otra.

Error 5: buscar la estrategia perfecta para un conflicto complicado. No existe. Si ort da conflictos, es porque hay una decisión humana que tomar. Cambiar de estrategia solo desplaza el problema o lo esconde. La respuesta correcta es la lección siguiente.

Consejo 1: -X ignore-space-change es el que más veces usarás. Cuando una fusión reviente con decenas de conflictos que al mirarlos son solo sangrado, aborta y reinténtalo con esa opción. La mejora es espectacular.

Consejo 2: comprueba lo que ha hecho una fusión rara. Después de cualquier fusión con -s o -X, mira el resultado antes de seguir:

Consejo 3: --no-commit es tu red de seguridad. En fusiones grandes o delicadas, párate antes de confirmar, ejecuta las pruebas y revisa. Cuesta treinta segundos y evita meter en main una combinación que nadie ha comprobado.

Consejo 4: documenta la política del equipo. Escribe en el README.md o en el CONTRIBUTING.md del proyecto cómo se integra en main. Es la clase de decisión que, sin escribir, cada persona interpreta de una forma.

Monta un repositorio de pruebas donde una rama aporte dos cosas: un fichero nuevo que no conflictúa y una modificación que sí conflictúa con la rama principal. Fusiona de las dos formas (en dos intentos independientes) y demuestra con comandos qué queda en cada caso.

Crea una rama con tres commits y intégrala en main de las dos formas, en dos repositorios distintos o deshaciendo entre medias. Después responde:

1. ¿Cuántos commits tiene main en cada caso?
2. ¿Cuántos padres tiene el último commit de main en cada caso?
3. ¿Qué dice git branch --merged en cada caso?
4. ¿Se puede borrar la rama con -d en cada caso?

Para cada situación, elige entre fusión normal, --no-ff, --squash, -s ours, octopus o --no-commit, y justifícalo:

1. Una rama de un compañero con 25 commits bien escritos y mensajes cuidados, que implementa el módulo de informes.
2. Tu propia rama con 7 commits, cuatro de los cuales se llaman wip.
3. Cinco ramas de traducción, cada una tocando un fichero de idioma distinto.
4. Una rama de un experimento que se ha decidido no llevar adelante, y de la que quieres dejar constancia.
5. Una fusión que afecta a la lógica de facturación y que quieres validar con las pruebas antes de que entre en main.

Solución 1:

Intento A, con la estrategia:

exclusivo.txt no está. Se ha descartado todo el contenido de la rama, incluido el fichero que no daba ningún problema.

Cero cambios respecto a main. Es la firma inconfundible de -s ours.

Intento B, con la opción:

exclusivo.txt sí está, porque no había conflicto con él. Y comun.txt tiene la versión de main porque ahí sí lo había y -X ours desempató a nuestro favor.

Conclusión: -s ours descarta todo; -X ours fusiona de verdad y solo desempata.

Solución 2:

Fusión normal:

Squash (repitiendo el montaje desde cero o deshaciendo con git reset --hard HEAD~1):

Un solo padre.

Respuestas:

1. 6 commits con fusión normal (base + 3 de la rama + avance de main + fusión); 3 con squash (base + avance de main + el commit aplastado).
2. Dos padres con fusión normal; uno con squash.
3. Con fusión normal, la rama aparece como fusionada; con squash, no.
4. Con fusión normal, -d funciona; con squash, hay que usar -D.

Solución 3:

1. Fusión con --no-ff. Veinticinco commits bien escritos son información valiosa que no hay que destruir, y el nodo de fusión documenta la integración del módulo como una unidad identificable.

2. --squash. Rama corta, propia y desordenada: el caso de manual. Un commit limpio en main con un mensaje escrito con calma vale más que siete commits de los que cuatro no dicen nada.

3. octopus (git merge trad-es trad-ca trad-en trad-fr trad-de). Cinco ramas que tocan ficheros distintos y por tanto no pueden conflictuar: es exactamente el escenario para el que sirve. Si alguna conflictuara, octopus fallaría y habría que integrarlas de una en una.

4. -s ours. Registra en el historial que la rama se ha considerado y descartado, sin traer su código, y deja de aparecer como pendiente de integrar. Aprovecha el mensaje del commit para explicar por qué se descartó.

5. --no-commit. Permite ejecutar la batería de pruebas sobre el resultado ya combinado y, si algo falla, salir limpiamente con git merge --abort sin que main llegue a contener nada.

Ya sabes que "fusionar" no es una sola cosa:

• Una estrategia es el algoritmo que combina las ramas, y se elige con -s. ort es la de por defecto desde Git 2.34: fusión a tres bandas con detección de renombrados y resolución recursiva cuando hay varios ancestros comunes. resolve es su predecesora simple; octopus fusiona tres o más ramas de golpe pero falla ante cualquier conflicto; subtree casa proyectos que viven en subdirectorios.
• La estrategia ours (-s ours) crea un commit de fusión y descarta todo el contenido de la otra rama. Sirve para cerrar formalmente una rama que se ha decidido no integrar.
• Las opciones -X ajustan la estrategia, no la sustituyen. -X ours/-X theirs desempatan solo los conflictos; -X ignore-space-change elimina de un plumazo los conflictos falsos por sangrado.
• -s ours y -X ours no tienen nada que ver. La estrategia decide todo; la opción decide solo los empates.
• El squash merge (--squash) deja el resultado preparado en el índice sin confirmar y sin registrar la fusión: el commit final tiene un solo padre y la rama no consta como fusionada. Ideal para ramas cortas y desordenadas; malo para funcionalidades cuyo historial merece conservarse.
• --no-commit hace la fusión de verdad pero se detiene antes de confirmar, permitiendo revisar y probar. A diferencia de --squash, la fusión sigue en curso y --abort funciona.
• La elección de cómo integrar es una decisión de equipo sobre el historial que se quiere tener, no una cuestión técnica.

Hemos dado por hecho durante toda la lección algo que en el mundo real no siempre ocurre: que la fusión sale bien. Pero Ana y Bruno no van a tener tanta suerte la próxima vez. Los dos están a punto de tocar las mismas líneas de la función que pinta el listado de tareas en app.js, cada uno en su rama y por motivos distintos.

Cuando eso pasa, Git no puede decidir. Se detiene, escribe unos marcadores extraños dentro del fichero y te pasa la pelota. En la siguiente lección, Resolviendo Conflictos de Fusión, provocaremos un conflicto de verdad y lo resolveremos paso a paso: aprenderás a leer los marcadores <<<<<<<, ======= y >>>>>>> (y el estilo diff3, que además te enseña qué había en el ancestro común), a orientarte con git status y git diff mientras la fusión está a medias, a usar los atajos --ours/--theirs, a abortar con git merge --abort cuando la cosa se tuerza, y a configurar una herramienta gráfica para los conflictos difíciles.