El comando `git history`

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

El nuevo comando experimental `history` de Git, que simplifica tareas comunes de `rebase` interactivo como fixups, splits y rewords, está generando reacciones encontradas entre los desarrolladores. Algunos celebran una forma menos friccionada de reescribir y limpiar el historial de commits —especialmente para enseñar a gente junior o mantener registros bien estructurados y aptos para `bisect`—, mientras que otros sostienen que la edición compleja del historial se usa en exceso, prefieren simples merges con squash o temen los problemas de UX y los conflictos. El debate se amplía hacia una crítica a la usabilidad de Git, el valor de los historiales curados frente a los lineales, y herramientas alternativas como jj, Magit, stgit y ayudantes semánticos de diff/merge.

Rol y utilidad de git history

  • Los nuevos subcomandos de git history (fixup, split, reword) se ven como envoltorios ergonómicos para flujos de trabajo comunes de git rebase -i.
  • Algunos prefieren ceñirse a rebase interactivo para tener un control preciso y “visual” sobre el orden y la edición de los commits.
  • Se aprecia la capacidad de git history fixup para reescribir automáticamente todas las ramas descendientes, especialmente en comparación con rebase --update-refs, que se comporta de forma más limitada.
  • Se señaló una limitación: git history actualmente elimina las firmas GPG de los commits reescritos, lo que empuja a algunos usuarios de vuelta a rebase -i.

Gestión de conflictos y problemas de UX

  • Fuerte desacuerdo sobre lo “asustantes” que realmente son los rebases y los conflictos.
    • Un lado: los conflictos son una parte normal de componer intenciones distintas; el miedo refleja una mala comprensión del código o del modelo de git.
    • El otro lado: incluso con buena comprensión, la UX en torno a los estados de rebase, “ours/theirs”, las herramientas interactivas y las ediciones a mitad de rebase resulta frágil y agotadora mentalmente.
  • Algunos sostienen que Git trata el código como texto plano; otros responden que los diffs basados en líneas son una aproximación pragmática y que pueden mejorarse con herramientas basadas en tree-sitter.

Redes de seguridad y recuperación

  • Varios recordatorios de que git rebase --abort, git reflog, las etiquetas/ramas ligeras y git reset hacen que experimentar sea seguro.
  • Varias personas crean habitualmente ramas “before-rebase” o usan sintaxis de reflog (por ejemplo, branch@{1}) para recuperar estados anteriores.

Flujos de trabajo: granularidad de commits, reescritura de historial y squashing

  • División clara:
    • Bando de “curar el historial”: commits pequeños, lógicos y fáciles de bisecar; el historial se usa para depuración, regresiones y entender la intención. Se fomenta reescribir el historial no fusionado; el squashing se ve como tirar valor a la basura.
    • Bando de “squash/append-only”: las PR como unidades atómicas; los commits internos son “registros de trabajo” ruidosos y deberían fusionarse con squash antes del merge. Énfasis en la eficiencia del revisor y el valor de negocio por encima del historial de grano fino.
  • Debate sobre si conservar commits de pruebas fallidas, commits de fixup y cadenas de revert es útil (como evidencia de TDD y arqueología) o perjudicial (rompe git bisect simple, complica blame).

Herramientas y alternativas

  • Varios recomiendan herramientas de nivel superior para domar la complejidad:
    • GUIs como TortoiseGit, Magit y lazygit.
    • Herramientas de pila de parches como stgit.
    • Sistemas más nuevos como jj, que muchos elogian conceptualmente pero encuentran aún ásperos en la interoperabilidad con Git.
  • Hay consenso en que mejores interfaces y vistas con estado reducen significativamente la carga cognitiva de las operaciones avanzadas de Git.

Curva de aprendizaje de Git y modelos mentales

  • Algunos insisten en que entender el modelo de datos interno de Git (mediante documentación/libros) hace que todo encaje y que muchas quejas se deben a no haber invertido ese tiempo.
  • Otros responden que la confusión generalizada indica problemas reales de UX, independientemente de la simplicidad teórica.