Facundo Uferer
Despegar commits y re-aplicarlos sobre la punta de main
git rebase ofrece un enfoque alternativo a git merge: en vez de crear un commit de unión, "despega" tus commits locales, mueve la base de tu rama hasta la punta de main y vuelve a aplicar (replay) tus cambios uno a uno con nuevos hashes.
✓ Historial continuo sin bifurcaciones. D' y E' son nuevos commits con hashes actualizados.
Merge vs Rebase: Criterio técnico y tradeoffs
Ninguna herramienta es superior en abstracto: ambas resuelven problemas distintos. Conoce los tradeoffs reales para elegir con madurez según las políticas de tu equipo.
Fusión Histórica
- ✓ Preserva la cronología exacta y la verdad histórica
- ✓ Nunca reescribe hashes SHA existentes (seguro)
- ✕ Crea commits de fusión redundantes ("Merge branch...")
- ✕ El grafo de ramas se vuelve un laberinto en equipos grandes
Para integrar Pull Requests completados en main y preservar contexto de equipo.
Autopista Lineal
- ✓ Historial perfectamente lineal, legible y estético
- ✓ Facilita enormemente git bisect para cazar bugs
- ✕ Reescribe los hashes SHA de los commits
- ✕ Peligroso si se aplica sobre ramas compartidas públicas
En ramas locales privadas antes de abrir PR para mantenerlas actualizadas con main.
La Regla de Oro: NUNCA hagas rebase en ramas públicas
Reescribir la historia de una rama en la que otros desarrolladores están trabajando obliga a todo el equipo a descartar sus árboles y reconstruir sus ramas manualmente. Romper esta regla destruye la confianza técnica.
Caso Seguro: Tu rama privada local
Estás trabajando en feat/mi-tarea en tu PC. Nadie más tiene esa rama. Hacer git rebase main es 100% seguro, profesional y recomendado.
git switch feat/mi-tarea
git rebase main Caso Prohibido: Ramas públicas (main / develop)
Hacer rebase en main y forzar el push con git push --force sobreescribe el árbol del servidor. Los commits de tus compañeros quedan huérfanos y desincronizados.
git push --force origin main # ✕ ¡NUNCA HAGAS ESTO! Conflictos en Rebase: ¡Aquí NO se usa git commit!
El error más frecuente de los juniors: al resolver un conflicto durante un rebase, ejecutan git commit y arruinan la secuencia. En un rebase, tras editar y hacer git add, se continúa con git rebase --continue.
Aparece el aviso: "Resolve all conflicts manually, mark them as resolved with git add...".
Borra <<<<<<<, =======, >>>>>>> y deja el código probado y funcional.
Indexa el archivo corregido en el Staging Area.
¡NO ejecutes git commit! Esta instrucción le indica a Git que aplique el commit actual y prosiga con el siguiente.
git rebase --abort Commits atómicos y la especificación Conventional Commits
Un repositorio profesional se distingue por la claridad de su historial. La especificación Conventional Commits estandariza prefijos semánticos para habilitar changelogs automáticos y versionado semántico.
feat(auth): validate JWT bearer token expiration✓ feat dispara una versión MINOR en SemVer (0.1.0 -> 0.2.0)
Gestión rigurosa de .gitignore y git rm --cached
Nunca subas archivos de dependencias, artefactos compilados ni variables de entorno con secretos. Si ya cometiste el error de agregar un archivo sensible, git rm --cached te permite quitarlo del índice sin borrarlo de tu disco.
# Dependencias
node_modules/
vendor/
# Variables de entorno y secretos
.env
.env.local
*.pem
# Compilación y builds
dist/
build/
*.class
# Archivos del sistema y del editor
.DS_Store
.idea/
.vscode/Si agregaste .env a .gitignore pero Git lo sigue rastreando, es porque ya estaba commiteado antes. Para dejar de rastrearlo sin borrar tu archivo local en disco:
git rm --cached .env
git commit -m "chore: stop tracking .env secret" 💡 El archivo permanecerá intacto en tu computadora pero desaparecerá del repositorio público.