La lección anterior terminó con un ejercicio incómodo: un BREAKING CHANGE perfectamente escrito desapareció al integrar la rama con squash merge, y la herramienta de versionado publicó como MINOR un cambio que rompía a todos los consumidores. El mensaje era impecable; lo que falló fue la política de integración.

Esta lección resuelve esa cuestión y, con ella, la que dejamos deliberadamente abierta en la lección 07-04: cuando llega el momento de fusionar una pull request, ¿merge, squash o rebase? Es probablemente la discusión más recurrente y más religiosa de todos los equipos que usan Git, y tiene respuesta razonada —aunque no sea la misma para todos los proyectos.

Pero antes hay que responder a una pregunta previa que casi nadie se hace: ¿limpio para qué? Un historial no es una obra de arte. Es una herramienta de trabajo con usos concretos y medibles. Un historial "bonito" que no sirve para ninguno de esos usos no es un historial limpio: es decoración cara.

1. Para qué sirve realmente un historial
2. El commit atómico
3. Cómo llegar a commits atómicos: add -p y rebase -i
4. La decisión de integración: merge, squash o rebase
5. Tabla comparativa a fondo
6. Qué política encaja con cada flujo
7. Recomendación razonada por tipo de proyecto
8. Limpiar antes de publicar, no tocar lo publicado
9. Commits de fusión: cuándo aportan y cuándo son ruido
10. Historial lineal frente a historial con topología
11. Los commits de formateo masivo y .git-blame-ignore-revs
12. Qué significa que un historial sea "bisecable"

Si nunca vas a mirar atrás, cualquier historial vale. La calidad del historial solo se paga cuando lo consultas, y se consulta para cinco cosas muy concretas. Todas ellas ya las conoces del curso:

Fíjate en que ninguno de los cinco pide un grafo bonito. Piden commits pequeños, autocontenidos, bien descritos y que funcionen. Ese es el objetivo real. La topología —lineal o con ramas— es un medio, no un fin, y por eso la discusión merge/squash/rebase solo se puede resolver preguntando cuál de estos cinco usos importa más en tu proyecto.

Definición de trabajo: un historial limpio es aquel en el que cualquier commit se puede entender, probar, revertir y atribuir por separado.

Un commit atómico es un commit que contiene un cambio completo y solo uno. Las dos mitades de la definición importan igual:

• Completo: no deja el proyecto roto. Compila, pasa las pruebas, la funcionalidad que toca funciona.
• Solo uno: no arrastra cambios que no tienen que ver con su propósito.

El caso patológico clásico, que todo el mundo ha cometido:

340 líneas cambiadas en app.js para "añadir un filtro". Dentro hay, con toda seguridad: el filtro (30 líneas), un reformateo del fichero entero al guardar con el editor (250 líneas), un renombrado de dos variables (20), una corrección de una errata sin relación (5) y la subida de una dependencia (el package.json).

Qué pierdes con ese commit:

• git blame sobre cualquier línea de app.js te lleva a él, aunque esa línea solo cambiara de indentación.
• Si el filtro tiene un fallo, git revert te obliga a revertir también la subida de la dependencia.
• git bisect lo señalará como culpable, pero el diff es tan grande que no habrás avanzado nada.
• El revisor no puede evaluarlo: 340 líneas de las que 250 son ruido.

Hay un test muy simple, y enlaza con la lección anterior: si no puedes describir el commit en un asunto de 50 caracteres sin usar "y", no es atómico. La incapacidad de nombrarlo es el síntoma.

La objeción práctica es real: "pero yo no programo así, yo voy tocando cosas". Nadie programa en commits atómicos. Los commits atómicos se fabrican después, con dos herramientas que ya dominas.

En la lección 02-04 vimos git add -p para preparar cambios por trozos. Ese es exactamente su propósito aquí: has tocado tres cosas en app.js y quieres tres commits.

Respondes y a los trozos del filtro y n a los demás, confirmas, y repites. Recuerda las teclas que más rentan:

Y una comprobación imprescindible antes de confirmar, porque preparar por trozos permite crear un commit que no compila:

Ese stash --keep-index de la lección 05-04 es la única forma honesta de verificar que un commit fabricado con add -p es realmente completo.

Si ya has confirmado y el resultado es un desastre, el rebase interactivo de la lección 05-02 lo arregla, siempre que no lo hayas publicado (apartado 8).

Se convierte en:

Y con reword en el primero, el resultado son dos commits limpios: feat(filtros): añade el filtro por etiqueta y test(filtros): cubre el filtrado por múltiples etiquetas.

Las tres órdenes que resuelven el 90 % de los casos:

Y el flujo que hace todo esto automático, de la lección 05-02: git commit --fixup=<sha> mientras trabajas, y git rebase -i --autosquash main al final.

Llegamos al punto. La rama GT-134-timeout-sync de Bruno tiene cuatro commits, está aprobada y va a entrar en main. Hay tres formas de hacerlo, y producen tres historiales distintos.

Partimos siempre de esta situación:

main ha avanzado con D mientras Bruno trabajaba, así que no hay avance rápido posible.

Los tres commits de Bruno entran tal cual, con sus SHA y sus fechas originales, y se añade un commit de fusión M con dos padres que marca dónde y cuándo se integró la rama. Es lo que vimos en la lección 03-03.

Los tres commits se funden en uno solo, S, con un mensaje nuevo. main queda lineal. La rama original sigue existiendo en el repositorio de Bruno, pero main no tiene ninguna referencia a ella: Git no sabe que S viene de C1, C2 y C3.

Los tres commits se reescriben encima de D (nuevos SHA, mismo contenido y mismo mensaje) y main avanza en línea recta. Es el rebase de la lección 05-01.

Las tres producen exactamente el mismo árbol de ficheros. El código final es idéntico byte a byte. Lo único que cambia es qué información queda registrada sobre cómo se llegó hasta ahí. Por eso la decisión no es técnica: es una decisión sobre qué información quieres poder recuperar dentro de un año.

1. revert frente a bisect. Squash gana en revert y en legibilidad; merge y rebase ganan en granularidad de bisect y en blame. Pregúntate qué haces más a menudo: ¿deshacer funcionalidades enteras, o cazar el commit exacto que rompió algo?

2. La calidad real de los commits de tu equipo. Si las ramas llegan con wip, wip2 y ahora sí, el merge y el rebase meten esa basura en main para siempre. El squash la absorbe. Squash es la política que protege de la indisciplina; merge y rebase son las que la premian cuando existe.

3. El tamaño de las pull requests. Con PRs de 200 líneas, un squash pierde poca información. Con PRs de 2.000 líneas, el squash produce commits monstruosos que arruinan blame y bisect a la vez. Squash y PRs pequeñas van juntos; es coherente con lo que dijimos sobre el tamaño de la PR en la lección 07-02.

Cada flujo del módulo 7 tiene una política que le sienta de forma natural:

Un matiz sobre Git Flow que se pasa por alto: en un repositorio con --no-ff sistemático, la lectura de alto nivel se hace con --first-parent (apartado 9), que oculta el interior de cada burbuja y deja solo la secuencia de integraciones. Sin esa herramienta, un historial con topología es efectivamente ilegible, y de ahí viene buena parte del rechazo al merge.

No hay una respuesta universal, pero sí hay respuestas defendibles según el proyecto:

Aplicación web con despliegue continuo, equipo de 3 a 15 personas → squash. Es el caso de gestor-tareas. Las PRs son pequeñas, cada una corresponde a un ticket GT-NNN, y lo que más se hace es responder a "¿qué cambió esta semana?" y "revierte eso que rompió producción". main queda con una línea por cambio, revert es trivial y bisect aterriza en la PR culpable, que es una granularidad suficiente cuando las PRs son de 200 líneas. Condición innegociable: el título del squash se escribe con el mismo cuidado que un commit (lección 08-01) y se propagan los trailers relevantes, incluidos Co-authored-by y BREAKING CHANGE.

Biblioteca o producto con versiones y soporte de varias ramas → merge --no-ff. Aquí hay que responder a "¿en qué versión entró esto?", "¿este parche está en la rama 2.x?" y "¿de qué release salió?". La topología es la respuesta, y git log --first-parent, git tag --contains y git branch --contains dependen de ella. Además, con cherry-pick entre ramas de mantenimiento (lección 05-03), tener los commits originales intactos facilita muchísimo el trabajo.

Proyecto de código abierto con muchos colaboradores externos → merge o squash, según la calidad de las contribuciones. El proyecto Git y el kernel de Linux usan merge con historial de topología, pero exigen a los contribuidores series de parches ya limpias. Un proyecto que no puede exigir eso hace mejor en aplastar.

Repositorio interno pequeño, 1 o 2 personas → lo que os resulte cómodo. Con dos personas y contexto compartido, la diferencia práctica es pequeña. Elegid uno y no le deis más vueltas.

Regla transversal, la que de verdad importa:

Elige una política, configúrala en la plataforma para que sea la única disponible, y escríbela en el README.md. Lo peor de todos los mundos es un main donde algunos aplastaron, otros fusionaron y otros rebasaron: no se puede leer con ninguna herramienta de forma consistente, --first-parent da resultados absurdos y nadie sabe qué esperar.

En gestor-tareas, el acuerdo escrito quedó así:

Todo lo del apartado 3 —rebase -i, fixup, reword, partir commits— tiene una frontera clarísima, y es la regla de oro de la lección 05-01:

Reescribe libremente lo que solo existe en tu máquina. No reescribas nunca lo que otros ya han descargado.

La razón, recordada en una frase: reescribir crea commits nuevos con SHA distintos. Quien tuviera los viejos se queda con dos versiones divergentes de la misma historia, y su siguiente pull produce un enredo que hay que deshacer a mano.

Hay un caso intermedio que hay que resolver explícitamente, porque genera discusiones eternas: tu rama de funcionalidad ya está en origin y abierta como PR, y quieres limpiarla antes de fusionar.

Es legítimo, con condiciones:

• La rama es tuya y nadie más ha basado trabajo en ella. Si Carla ha hecho un commit encima, ya no.
• Usas siempre git push --force-with-lease (lección 04-05), nunca --force a secas: si alguien ha enviado algo mientras tanto, la operación se rechaza en lugar de destruirlo.
• Avisas en la PR. Los revisores pierden el hilo de sus comentarios cuando los SHA cambian.
• Si ya hay comentarios de revisión, añade commits nuevos en lugar de reescribir, y aplasta al final con el squash de la fusión. Es la razón principal por la que el squash es tan popular: hace innecesario el rebase de limpieza.
• Para revisar qué cambió entre la versión anterior y la reescrita, git range-diff de la lección 07-02.

Nunca, bajo ninguna circunstancia: reescribir main, una rama de release, o una rama compartida. Si algo hay que deshacer allí, se deshace con git revert (lección 05-06), que añade un commit nuevo en lugar de borrar el viejo.

No todos los commits de fusión son iguales. Hay dos clases y conviene distinguirlas.

Son las deliberadas: git merge --no-ff de una rama de funcionalidad a main. El commit registra una decisión —"esta funcionalidad se integró aquí"— y su mensaje puede documentarla:

Ese commit es información pura, y con --first-parent produce un historial de alto nivel excelente.

Son las accidentales: las que aparecen al hacer git pull cuando el remoto ha avanzado.

Ese commit no registra ninguna decisión. Registra que Carla hizo pull un martes a las 11:40. Un main con doscientos de estos es ilegible, y llenan el grafo de burbujas que no significan nada.

La cura es la de la lección 04-04, y debería estar en la configuración global de todo el mundo:

O, si prefieres que Git te obligue a decidir en vez de elegir por ti:

Un commit de fusión tiene dos padres: el primero es la rama donde estabas (main) y el segundo es la que fusionaste. --first-parent sigue únicamente el primero, con lo que oculta el contenido interno de cada rama y deja solo la secuencia de integraciones.

De cientos de líneas a una decena. Este es el argumento que rescata al merge: un historial con topología no es ilegible, es un historial con dos niveles de lectura. El de alto nivel se obtiene con --first-parent, y el detalle sigue estando ahí cuando lo necesitas.

Merece un alias, retomando los de la lección 06-04:

--first-parent funciona también en otros comandos:

Ese git bisect --first-parent es especialmente útil: convierte un historial con merges en algo con la misma granularidad que un historial de squash, pero sin perder el detalle cuando quieres bajar.

La última fila es la tensión de fondo, y merece decirse claramente: un historial lineal es una ficción útil. Nadie trabajó en ese orden. Ana y Bruno programaron a la vez durante tres días; el historial lineal cuenta que uno terminó y luego empezó el otro. La pregunta honesta no es "¿qué es más verdadero?" sino "¿me sirve de algo la verdad concurrente?". Para la mayoría de los productos, no. Para un proyecto con soporte de varias versiones en paralelo, sí, y mucho.

Hay un tipo de commit que rompe el historial más que ningún otro, y no es un commit malo: es necesario. El día que el equipo de gestor-tareas decidió adoptar Prettier, Ana ejecutó el formateador sobre todo el proyecto:

El daño: a partir de ese momento, git blame app.js atribuye todas las líneas del fichero a Ana y a ese commit. Toda la información de autoría e intención de los últimos dos años queda enterrada bajo un commit que no cambió ni una coma de comportamiento.

Las reglas para que duela lo mínimo:

1. Aísla el formateo en su propio commit. Nunca mezclado con cambios funcionales: es la aplicación más importante del principio del commit atómico.
2. Que ese commit no cambie el comportamiento. Solo el formateador; nada a mano. Debe poder reproducirse ejecutando la herramienta.
3. Dilo en el mensaje, incluida la versión de la herramienta y su configuración, para que sea reproducible.
4. Regístralo en .git-blame-ignore-revs.

Ese fichero, que vimos en la lección 06-03 y que ahora cerramos, es una lista de SHA que git blame debe atravesar como si no existieran:

Requisitos: SHA completos de 40 caracteres (los abreviados no valen) y una línea por commit.

Se usa así:

Con esa configuración local, git blame app.js vuelve a mostrar los autores reales de cada línea. Las plataformas de alojamiento más habituales reconocen el fichero por su nombre convencional y lo aplican automáticamente en su vista de blame.

El detalle que hay que documentar en el README.md: blame.ignoreRevsFile es configuración local (lección 01-05), así que no viaja con el clon. El fichero sí está versionado, pero cada persona tiene que activarlo. Añádelo al script de puesta en marcha del proyecto:

En la lección 06-02 dijimos que git bisect solo es útil sobre un historial "bisecable" y remitimos aquí. Ya tenemos todas las piezas para definirlo.

Un historial es bisecable cuando cualquier commit escogido al azar se puede compilar, arrancar y probar.

git bisect funciona por búsqueda binaria: te planta en un commit intermedio y te pregunta si está bien o mal. Si ese commit ni siquiera compila, no puedes responder ninguna de las dos cosas. Tienes que marcarlo git bisect skip, y cada skip degrada la búsqueda. Con suficientes commits rotos, la bisección deja de converger y no sirve de nada.

1. Commits atómicos y completos: apartado 2. Cada uno deja el proyecto funcionando.
2. El código y sus pruebas, en el mismo commit.
3. CI sobre cada commit, no solo sobre la punta de la rama. Es la única comprobación real. Con la validación de la lección 07-06, se puede ejecutar la compilación sobre cada commit de la PR:

4. git rebase --exec, de la lección 05-02, para comprobarlo tú antes de publicar. Es la herramienta perfecta para esto:

Si el rebase se para, tienes un commit no bisecable en la rama. Lo arreglas con edit o fixup y continúas.

Cierra el círculo del apartado 4:

• Squash garantiza la bisecabilidad casi gratis: cada commit de main es una PR entera, que pasó el CI. La granularidad es gruesa, pero nunca falla.
• Merge con --first-parent da lo mismo que el squash, y permite bajar al detalle cuando la PR es grande.
• Rebase da la granularidad más fina, pero solo si cada commit compila, lo cual exige disciplina y una comprobación como la de arriba.

Error 1: confundir "limpio" con "bonito". Un grafo con una sola línea recta que no permite revertir, bisecar ni entender nada no es limpio. Los cinco usos del apartado 1 son el criterio; la estética no.

Error 2: mezclar políticas de integración en el mismo repositorio. Es peor que elegir la política equivocada. Configúrala en la plataforma dejando una sola opción activa.

Error 3: aplastar PRs enormes. Un squash de 2.000 líneas destruye blame y deja bisect sin granularidad. Squash exige PRs pequeñas; si no las tienes, arregla eso primero.

Error 4: perder el BREAKING CHANGE en el squash. Es lo que vimos en el ejercicio 3 de la lección 08-01. El cuadro de mensaje del squash sale prerrellenado con la concatenación de todos los commits; léelo y edítalo, no lo aceptes tal cual ni lo vacíes.

Error 5: rebasar una rama compartida. La regla de oro de la 05-01 no tiene excepciones prácticas. Si dudas de si alguien más la tiene, no la rebases.

Error 6: acumular fusiones de pull. git config --global pull.rebase true y desaparecen. Es un cambio de una línea que mejora el historial de por vida.

Error 7: hacer el formateo masivo mezclado con un cambio funcional. Enterrarás el cambio funcional en 900 líneas de ruido y arruinarás el blame sin posibilidad de rescate, porque .git-blame-ignore-revs no puede ignorar un commit que además contiene código real.

Error 8: pensar que --first-parent no existe. Mucha gente rechaza el merge por "ilegible" sin haber probado nunca git log --first-parent. Pruébalo antes de decidir.

Consejo 1: escribe la política en el README.md. Con las condiciones (tamaño de PR, formato del título, trailers). Diego, que viene de fuera, la necesita antes de su primera PR.

Consejo 2: git rebase main --exec "npm test" antes de abrir la PR. Es la forma más barata de garantizar que tu rama es bisecable.

Consejo 3: alias para leer. git config --global alias.integraciones "log --oneline --first-parent --decorate".

Consejo 4: revisa tu rama antes de publicarla. git log --oneline main..HEAD. Si ves un wip, todavía te queda trabajo.

Consejo 5: .git-blame-ignore-revs desde el primer commit. Créalo vacío, con la cabecera comentada. Así, el día del primer formateo masivo, el sitio ya existe.

Consejo 6: borra las ramas fusionadas. Con squash, la rama no queda enlazada desde main; dejarla viva sugiere que hay trabajo pendiente. Recuerda git branch --merged y git fetch --prune de la lección 03-06.

Monta un repositorio de pruebas que reproduzca la situación del apartado 4: main con dos commits, una rama con tres commits y un commit posterior en main. Luego, desde tres copias del mismo estado, integra la rama con cada una de las tres políticas.

Para cada resultado, responde:

1. ¿Cuántos commits tiene main?
2. ¿Qué muestra git log --oneline --graph?
3. ¿Qué muestra git log --oneline --first-parent?
4. ¿Qué comando exacto usarías para deshacer la integración completa?
5. Si bisect señalara el problema, ¿a qué nivel de detalle te dejaría?

Simula el commit patológico del apartado 2:

1. Crea un app.js con tres funciones y confírmalo.
2. En un solo cambio, modifica una función (cambio funcional), reindenta otra (formateo) y corrige una errata en un comentario de la tercera.
3. Usa git add -p (con s y e cuando haga falta) para separar los tres en tres commits atómicos con mensajes en Conventional Commits.
4. Verifica con git stash push --keep-index que el primer commit funciona por sí solo.
5. Comprueba con git log --oneline --stat que cada commit toca solo lo suyo.

1. Crea un repositorio con un estilos.css de unas 20 líneas, escrito en tres commits de tres autores distintos (usa git -c user.name=... -c user.email=... commit).
2. Comprueba con git blame estilos.css que la autoría es correcta.
3. Aplica un reformateo masivo (por ejemplo, cambia toda la indentación) y confírmalo como style: reindenta estilos.css a 2 espacios.
4. Comprueba el daño con git blame.
5. Crea .git-blame-ignore-revs, configura blame.ignoreRevsFile y demuestra que la autoría original se recupera.
6. Explica por qué el paso 5 habría sido imposible si el reformateo hubiera venido mezclado con un cambio funcional.

Solución 1:

Las respuestas:

Observa la fila 4: con rebase, deshacer la integración exige revertir tres commits en orden inverso, y si el intermedio depende del primero, hay conflictos. Es la desventaja más práctica del rebase puro.

Solución 2:

Si los cambios estuvieran en el mismo trozo, s los parte y e permite editar el trozo a mano, dejando con - las líneas que no quieres preparar.

En la práctica se hace antes de confirmar: preparas el trozo, git stash push --keep-index aparta todo lo demás, ejecutas las pruebas sobre exactamente lo que va a entrar, y solo entonces confirmas y haces git stash pop.

Solución 3:

Ahora todas las líneas indentadas aparecen a nombre de Ana y del commit de estilo.

6. Porque .git-blame-ignore-revs funciona saltando el commit entero: cuando blame encuentra ese SHA, atribuye la línea al commit anterior que la tocó. Si el commit contuviera además un cambio funcional real, ignorarlo atribuiría también ese cambio funcional a quien no lo hizo, y perderías la información de quién introdujo el código de verdad. El fichero solo es seguro con commits que demostrablemente no cambian el comportamiento. Por eso la regla 1 del apartado 11 —aislar el formateo— no es un consejo estético: es la condición que hace posible el rescate.

Lo esencial de esta lección:

• Un historial es limpio cuando cualquier commit se puede entender, probar, revertir y atribuir por separado. Los cinco usos reales —blame, bisect, revert, revisión y auditoría— son el criterio; la estética del grafo no lo es.
• El commit atómico —un cambio completo y solo uno— es la unidad que hace posible todo lo demás. No se programa así: se fabrica después, con git add -p antes de confirmar y con git rebase -i después.
• La decisión que dejamos abierta en la 07-04 queda cerrada así:
  • Merge --no-ff cuando la topología es información: Git Flow, bibliotecas con varias versiones vivas, proyectos con ramas de mantenimiento. Se lee con --first-parent.
  • Squash cuando lo que importa es que main sea una lista legible de cambios desplegables: GitHub Flow, aplicaciones web, equipos cuyas ramas llegan con wip. Exige PRs pequeñas y un título de squash escrito con cuidado.
  • Rebase cuando quieres granularidad fina y linealidad a la vez, y el equipo tiene la disciplina para que cada commit compile: Trunk Based Development.
  • Y por encima de las tres: elige una, configúrala como única opción en la plataforma y escríbela en el README.md. Mezclarlas es peor que elegir mal.
• Se limpia antes de publicar; no se toca lo publicado. La regla de oro de la 05-01 se mantiene, con la única zona gris de tu propia rama de PR, y siempre con --force-with-lease y aviso previo.
• Los commits de fusión deliberados son información; los accidentales de git pull son ruido que se elimina con pull.rebase true. Y --first-parent convierte un historial con topología en un historial de dos niveles de lectura, lo que rescata al merge de la acusación de ilegible.
• Un formateo masivo se aísla en su propio commit, se documenta y se registra en .git-blame-ignore-revs con el SHA completo, activándolo con blame.ignoreRevsFile. Aislarlo no es estética: es lo que hace posible el rescate.
• Un historial es bisecable cuando cualquier commit compila y se puede probar. Se garantiza con commits atómicos, con el código y sus pruebas juntos, con git rebase --exec antes de publicar y con CI sobre cada commit.

gestor-tareas tiene ya mensajes que explican el porqué y un historial que se puede leer, bisecar y revertir. Pero sigue teniendo dentro cosas que no deberían estar ahí: la carpeta node_modules que Bruno subió sin darse cuenta, los .DS_Store de macOS, los Thumbs.db de Windows y un fichero de configuración con una contraseña.

Lo siguiente es decidir qué no entra nunca en un repositorio, en la lección 08-03: Ignorando Archivos con .gitignore.