Cómo hacer un squash commit en local con Git paso a paso

La forma más flexible de comprimir varios commits en uno solo, en local y antes de subir nada, es el rebase interactivo. La palabra “squash” suena agresiva, pero el procedimiento es sorprendentemente llevadero una vez lo has hecho un par de veces.

Aquí va el paso a paso.

Paso 1: Cuenta cuántos commits quieres agrupar

Antes de lanzar nada, mira el historial reciente para ver qué commits quieres fusionar:

git log --oneline

Imagina que ves esto y quieres agrupar los tres últimos commits en uno solo (el primero, C1):

• C3 (HEAD) → “Arreglo tipográfico”
• C2 → “Añadidos tests para la función X”
• C1 → “Implementada función X”

El objetivo: que en el repositorio quede un único commit que diga algo como feat: implementar función X con sus tests. Limpio, profesional, fácil de revisar.

Paso 2: Lanza el rebase interactivo

Para agrupar los últimos 3 commits, usa HEAD~3:

git rebase -i HEAD~3

También puedes usar el hash del commit anterior al bloque que quieres modificar, por ejemplo git rebase -i 1a2b3c4. Ambas formas son equivalentes; yo tiendo a usar HEAD~n cuando el bloque es reciente porque es más rápido de escribir.

Paso 3: Marca los commits a comprimir en el editor

Se abrirá un editor de texto con la lista de commits. Ojo: aparecen en orden inverso al git log, con el más antiguo arriba y el más nuevo abajo.

Verás algo así:

pick 1a2b3c4 Implementada función X
pick 5e6f7g8 Añadidos tests para la función X
pick 9z8y7x6 Arreglo tipográfico

# Commands:
# p, pick <commit> = use commit
# s, squash <commit> = use commit, but meld into previous commit

Para fusionar C2 y C3 dentro de C1, mantén el primer commit con pick y cambia pick por squash (o simplemente s) en los commits que quieres absorber. Quedaría así:

pick 1a2b3c4 Implementada función X
s 5e6f7g8 Añadidos tests para la función X
s 9z8y7x6 Arreglo tipográfico

La regla es simple: el commit marcado como pick se mantiene tal cual; todos los que estén por debajo marcados como squash se funden dentro de él.

Cómo guardar según el editor que se abra

• Vim: Esc, luego :wq y Enter.
• Nano: Ctrl+O, Enter (guardar), luego Ctrl+X (salir).
• VS Code: edita, Ctrl+S y cierra la pestaña con Ctrl+W.

Paso 4: Escribe el mensaje del commit resultante

En cuanto cierres el editor anterior, Git abrirá un segundo editor. Aquí verás los mensajes de los commits que estás fusionando, combinados y comentados:

# This is a combination of 3 commits.
# This is the 1st commit message:

Implementada función X

# This is the 2nd commit message:

Añadidos tests para la función X

# This is the 3rd commit message:

Arreglo tipográfico

Lo que tienes que hacer:

1. Borra los mensajes antiguos y todas las líneas que empiezan por # que no quieras conservar.
2. Escribe el mensaje definitivo del commit fusionado. Por ejemplo: feat: implementar función X junto con sus pruebas unitarias.
3. Guarda y cierra con el mismo atajo que en el paso anterior.

Paso 5: Verifica que el historial quedó como esperabas

Si el rebase terminó bien, Git te mostrará un mensaje confirmándolo. Para asegurarte, vuelve a revisar el log:

git log --oneline

Deberías ver un solo commit donde antes había tres, con el mensaje nuevo que escribiste.

Bonus: qué hacer si algo sale mal

El rebase interactivo da respeto la primera vez, sobre todo por miedo a perder trabajo. Hay dos redes de seguridad que conviene tener siempre a mano.

Cancelar a mitad del proceso

Si te equivocas con las palabras clave o simplemente te arrepientes, puedes abortar y dejar el repositorio tal como estaba antes de empezar:

git rebase --abort

El árbol vuelve al estado exacto en el que estaba. Nada se pierde.

Recuperar un commit “perdido” tras un rebase

Si ya terminaste el rebase pero algo salió mal (por ejemplo, el mensaje final no es lo que querías o se fusionó un commit de más), Git no borra los commits antiguos inmediatamente. Quedan en el reflog:

git reflog

Busca el hash del commit justo antes del desastre y vuelve a él con un reset hard:

git reset --hard <hash-de-tu-commit-original>

El reflog es tu mejor amigo. Git es muy bueno recuperando estados pasados, siempre que el commit no haya sido purgado con git gc agresivo. La regla que sigo: si algo ha ido mal, no panic, mira el reflog antes de hacer cualquier otra cosa.