Por qué squash

Una rama de feature suele acumular commits de "WIP", "fix typo" y "atendiendo review" que entierran la intención. El squash los condensa en un pequeño número de commits lógicamente significativos antes del merge. Los revisores ven historia limpia; bisect funciona sobre unidades reales de cambio.

Squash en el merge

git checkout main
git merge --squash feature
git commit -m "Añadir feature X"

Squash con rebase interactivo

git rebase -i main

Cambia pick por squash (mantener ambos mensajes) o fixup (descartar el mensaje del squash) en las líneas que quieras colapsar.

Flujo de autosquash

git commit --fixup=<sha>
git commit --squash=<sha>
git rebase -i --autosquash main

Configura git config rebase.autoSquash true.

Reordenar para claridad

Durante el rebase interactivo, intercambia líneas para reordenar. Si un refactor debe preceder a un feature, asegúrate de que el commit del refactor venga primero.

Dividir commits demasiado grandes

git reset HEAD^
git add -p src/parser.c
git commit -m "Refactor parser"
git add -p src/runtime.c
git commit -m "Refactor runtime"
git rebase --continue

Errores comunes

Hacer squash entre un merge colapsa dos ramas en un mega-commit. Hacer squash de commits ya pushed obliga a los colaboradores a hacer rebase. Apunta a varios commits enfocados, no uno gigante.

Preservar autores

git commit -m "Añadir feature X

Co-authored-by: Alice <[email protected]>
Co-authored-by: Bob <[email protected]>"