El debate entre merge y rebase

Artículo original ↗ Discusión en Hacker News ↗

Los usuarios de Git siguen divididos sobre si los commits de merge, el rebase o el squash producen el historial de proyecto más útil. Quienes apoyan los flujos de rebase y squash valoran una rama principal lineal y “curada” que simplifica `git bisect`, los reverts y el razonamiento sobre los cambios, especialmente a gran escala o en desarrollo basado en trunk. Los críticos responden que reescribir el historial es frágil, oculta lo que realmente ocurrió y puede ser demasiado propenso a errores para equipos menos experimentados, defendiendo en cambio flujos de trabajo basados en merges o en parches donde se preservan historiales desordenados pero precisos y la complejidad la absorben las herramientas, no los desarrolladores.

Merge vs. Rebase (and Bisectability)

  • Muchos sostienen que los historiales lineales gestionados con rebase hacen que git bisect y el razonamiento sobre los cambios sean mucho más fáciles; los historiales con muchos merges se describen como “bolas de pelo” que a menudo reducen bisect a “algo en algún lugar de este gran merge”.
  • Otros responden que git log --first-parent y las opciones de bisect mitigan la complejidad de los merges, y que los commits de merge bien estructurados pueden ser tan comprensibles como los aplastados.
  • Algunos subrayan que los rebases grandes y llenos de conflictos son dolorosos y propensos a errores, especialmente en repos activos con múltiples colaboradores.

Squash Merges and Commit Granularity

  • A favor del squash: main/trunk debería contener unidades atómicas y revertibles (PRs o conjuntos de cambios), no ruido de “wip/fix typo”; el squash se considera la forma más sencilla de mantener limpio el historial cuando la higiene de commits es pobre.
  • En contra del squash: aplastar commits puede enterrar pasos lógicos importantes (por ejemplo, introducción de un helper, refactors mecánicos, un cambio delicado en un caso límite) en un único diff enorme, lo que complica blame, la revisión y la comprensión futura.
  • Varios adoptan una estrategia mixta: aplastar PRs ruidosos y conservar commits estructurados cuidadosamente mediante merges rebase+ff.

Workflows and Branching Models

  • Ejemplos de flujos de trabajo:
    • Aplastar ramas de funcionalidad en staging y luego hacer merge de staging → master para las releases.
    • Desarrollo basado en trunk o ramas de vida muy corta con despliegues frecuentes frente a ramas de funcionalidad de 2–3 semanas.
  • Algunos equipos valoran reglas coherentes y simples (por ejemplo, “siempre squash”) para reducir la carga cognitiva; otros prefieren “depende”, eligiendo por PR.

Tooling and Alternatives

  • Herramientas como Sapling y git-absorb son elogiadas por hacer más fáciles los diffs apilados y la limpieza de commits (por ejemplo, reamendar automáticamente ediciones al commit correcto).
  • Algunos ven el modelo de Git (ramas como punteros, historial de merges incómodo) como una limitación fundamental; se mencionan alternativas como Mercurial o flujos de trabajo basados en parches/apilados como conceptualmente más limpios.

Philosophy: “Accurate” vs “Curated” History

  • Un bando quiere que el historial refleje lo que realmente ocurrió, incluidos falsos comienzos y commits desordenados, argumentando que reescribir el historial es “mentir” y puede dificultar auditorías o depuración.
  • El otro bando ve el historial como una narrativa curada de cambios lógicos, no como un cuaderno de laboratorio inmutable; priorizan la legibilidad, pasos lógicos más pequeños y una arqueología más fácil por encima de registrar cada tropiezo.
  • Ambos lados coinciden en que la disciplina en los commits y una “guía de estilo git” compartida importan más que cualquier regla única.