Git rebase -I no da tanto miedo

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

`git rebase -i` se presenta como una herramienta poderosa pero poco utilizada para remodelar el historial de commits, y muchos desarrolladores sostienen que una fluidez básica en ella —y en el modelo de datos subyacente de Git— es esencial para el trabajo serio de software. Los comentaristas comparten flujos de trabajo concretos (fixup/autosquash, `git add -p`, uso de reflog, etiquetas y ramas desechables) para hacer el rebase más seguro y menos intimidante, y señalan integraciones con editores y herramientas más nuevas como `jj` y `git history` que agilizan aún más el proceso. Otros reaccionan contra la “pureza del rebase”, cuestionando cuánto ayuda realmente un historial meticulosamente curado en comparación con flujos de trabajo de merge más simples, especialmente dada la interfaz confusa de Git y el riesgo de conflictos.

Sentimiento general sobre git rebase -i

  • Muchos comentaristas ven el rebase interactivo como una habilidad central, nada intimidante, que da un control preciso sobre el historial, mejora las revisiones y debería formar parte del conjunto de herramientas de todo desarrollador.
  • Otros lo consideran sobrevalorado, tedioso o innecesario para flujos de trabajo simples, y critican la CLI confusa de Git y el “culto al rebase” en torno a historiales impecables.

Curva de aprendizaje, comprensión de Git y cultura

  • Postura fuerte: si te da miedo el rebase, realmente no entiendes el modelo de datos de Git; invertir unas pocas horas compensa a lo largo de una carrera. Algunos incluso tratan el miedo al rebase como una señal de alarma en entrevistas.
  • Postura opuesta: la UX de Git es objetivamente mala; muchos equipos solo necesitan un pequeño subconjunto, y centrarse mucho en el rebase en las entrevistas es en sí mismo una señal de alarma.
  • Algunos presentan el dominio del shell, del editor y del VCS (incluido el rebase) como las tres “tardes” esenciales de aprendizaje.

Seguridad, recuperación y copias de seguridad

  • Se enfatiza que los datos confirmados son difíciles de perder de verdad; reflog, ORIG_HEAD y refs mágicas permiten deshacer rebases fallidos.
  • Otros señalan que esto presupone conocer reflog y poder interpretarlo; recomiendan salvaguardas de baja tecnología: ramas temporales, etiquetas como puntos de guardado, o incluso copiar .git.
  • Varios destacan que hosts como GitHub rara vez hacen garbage collection, así que los commits enviados pueden vivir prácticamente para siempre, lo que es a la vez red de seguridad y riesgo de seguridad.

Estrategias para manejar conflictos

  • Los temores comunes se centran en errores sutiles durante la resolución de conflictos, no en el rebase en sí.
  • Mitigaciones: merge.conflictStyle=zdiff3/diff3, git rerere, range-diff y comparar los head antes y después del rebase.
  • Tácticas incluyen: abortar rebases grandes y desordenados; hacer primero squash; reordenar y luego hacer un pase aparte de autosquash; o reiniciar ramas cuando los conflictos se vuelven demasiado complejos.

Flujos de trabajo, herramientas y alias

  • Uso intensivo de --fixup/--squash con --autosquash; edit para dividir o modificar commits antiguos; git add -p/staging parcial.
  • Algunos prefieren GUIs/TUIs (GitLens, magit, git gui) para el rebase interactivo o el staging por fragmentos.
  • Varios comparten alias y configuraciones para agilizar los flujos de trabajo de amend/fixup; uno advierte contra enseñar flags cortos a principiantes.

Alternativas y automatización

  • Se mencionan alternativas como jj, Fossil, Mercurial y los comandos en evolución de Git (switch, restore, history, maintenance) como intentos de mejorar la UX.
  • Unos pocos dicen que ahora delegan en gran medida rebases/commits a agentes o LLM, con advertencias de hacer commit o stash primero.