Cómo hacer commit de una parte de un archivo en Git

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

Dividir los cambios en commits pequeños y centrados en Git es valorado como vital para depuración, revisión de código y reversiones seguras, aunque muchos desarrolladores optan por hacer squash de pull requests enteras o agrupar ediciones no relacionadas. Los comentaristas comparan flujos de trabajo que exigen commits atómicos y siempre válidos con otros que favorecen historiales de una PR por commit, y debaten los méritos de herramientas de línea de comandos como `git add -p` frente a GUIs e integraciones en IDEs (VS Code, JetBrains, Magit, lazygit, etc.) para preparar partes de archivos. En general, la conversación destaca que dominar los commits parciales y dar forma al historial con criterio es una habilidad central, aunque a menudo descuidada, en el desarrollo profesional de software.

Granularidad de los commits y valor de un buen historial

  • Muchos sostienen que dividir los cambios en commits pequeños y coherentes está infravalorado y es muy útil, especialmente para depurar y revertir caídas.
  • Otros señalan que, en la práctica, algunos equipos rara vez revierten commits específicos; en su lugar, deshacen despliegues o escriben un nuevo commit de “fix”.
  • Hay un fuerte sentimiento de que construir buenos commits (y aprender bien Git) es una habilidad poco apreciada, vinculada a preocupaciones más amplias sobre la calidad del software frente a la productividad de “simplemente sacar la tarea adelante”.

Squash vs. commits incrementales, y reverts

  • Un bando prefiere squash-merge por PR:
    • La PR es la unidad de revisión, no cada commit intermedio.
    • Da como resultado un historial lineal y apto para bisect, sin estados intermedios rotos.
    • Los squashes ayudan a eliminar commits ruidosos de “corrige typo / ahora sí funciona” y a reescribir un único buen mensaje.
  • El bando opuesto favorece commits atómicos sin squash:
    • Cada commit debería compilar y pasar tests, facilitando bisect y reversiones más granulares.
    • Squashear puede perder contexto importante (por ejemplo, movimientos de archivos y refactors) y dificulta la búsqueda seria de bugs.
  • Algunos señalan que, si squashear produce bloques ilegibles, probablemente la PR es demasiado grande o mezcla temas.
  • Hilo aparte sobre estrategias de merge:
    • Algunos recomiendan usar rebase en ramas de feature pero commits de merge en la rama principal, logrando tanto commits agrupados por PR como un historial lineal por commit (--first-parent frente a --no-merges).
    • Otros simplemente vuelven a la última release buena en lugar de rastrear commits malos individuales.

Herramientas y flujos de trabajo para commits parciales

  • Gran división entre CLI y GUI/TUI:
    • Fans de la CLI: git add -p/--patch, además de sus equivalentes en git reset y git checkout; se elogia por ser rápido, ubicuo y bueno para forzar una revisión cuidadosa. Opciones como “split” y “edit” permiten un staging muy granular, incluyendo ediciones de una sola línea.
    • Críticos: consideran que la UI interactiva de git add -p es confusa, carece de contexto y es inferior a la selección por líneas en GUIs.
  • Alternativas populares mencionadas:
    • TUI/CLI: lazygit, tig, stgit, git gui, git-cola, git-crecord, magit (Emacs), vim-fugitive.
    • IDE/GUI: VS Code (“stage selected ranges”, aunque con errores anteriores de CRLF), JetBrains changelists, GitHub Desktop, SourceTree, Sublime Merge.
  • Varios señalan que el staging parcial es fácil y ergonómico en IDEs modernos, y que distintas herramientas se adaptan a distintos flujos de trabajo.

Tensión más amplia entre calidad y velocidad

  • Algunos sostienen que “ser productivo” a menudo significa entregar rápido a costa de la calidad del código y del historial.
  • Otros enfatizan el coste a largo plazo de protocolos y código “mal hechos”, que se vuelven difíciles de reemplazar una vez adoptados ampliamente.