Mucha gente empieza a usar Git con solo tres comandos: git add ., git commit y git push. Y funciona, hasta que aparece el primer merge conflictivo, alguien borra una rama sin querer, hay que averiguar qué cambio rompió producción, o dos tareas urgentes necesitan tocar el mismo repositorio a la vez. Ahí Git deja de ser un simple sitio donde guardar código y empieza a enseñar para qué se diseñó realmente.
Los comandos de Git que marcan la diferencia, en 30 segundos
- Git puede inspeccionar, comparar y recuperar estados del proyecto, no solo guardar versiones.
git add -p,git diffygit statusevitan commits accidentales antes de que lleguen al repositorio.bisectlocaliza el commit que introdujo un bug mediante búsqueda binaria.reflogrecupera referencias que parecían perdidas tras unreseto unrebase.worktree,range-diff,rerereyfixupson especialmente útiles en flujos de trabajo más avanzados.
El cambio importante llega cuando entiendes que los commits forman un historial enlazado y que las ramas, las etiquetas y HEAD son referencias a puntos concretos de ese historial. Muchos comandos que al principio parecen difíciles empiezan a tener bastante más sentido en cuanto se ve esa idea.
Git también ha evolucionado. Las versiones actuales siguen admitiendo checkout, pero comandos como switch y restore separan operaciones que históricamente estaban todas metidas en uno solo.
Van 18 comandos y combinaciones que merece la pena incorporar al día a día, con varios especialmente útiles para sysadmins y equipos que mantienen repositorios grandes.
Antes de tocar el historial: mira qué está pasando
1. git status: dos segundos que evitan muchos disgustos
Puede sonar demasiado básico para abrir una lista avanzada, pero sigue siendo uno de los mejores hábitos antes de hacer cambios importantes.
git status
Muestra la rama actual, las modificaciones pendientes, los archivos en staging y los que todavía no están rastreados.
Antes de un commit, un rebase, un cambio de rama o un despliegue, saber exactamente en qué punto está el repositorio evita trabajar sobre una suposición falsa.
2. git diff: revisa antes de enviar
Para ver los cambios que todavía no están en staging:
git diff
Y para revisar exactamente qué va a entrar en el próximo commit:
git diff --staged
Este segundo comando debería formar parte de la rutina de casi cualquier equipo. Puede sacar a la luz desde un console.log olvidado hasta una contraseña, un token, un cambio de configuración o, simplemente, código que pertenece a otra tarea.
3. git add -p: deja de meter todo en staging a ciegas
Hay un hábito que conviene abandonar, el de escribir siempre:
git add .
Git tiene staging interactivo:
git add -p
En vez de meter automáticamente cada modificación, presenta los cambios en fragmentos y deja decidir cuáles pertenecen al commit.
Es especialmente útil cuando un mismo archivo mezcla un arreglo urgente con trabajo que no tiene nada que ver.
El resultado son commits más pequeños, más limpios y más fáciles de entender.
4. git grep: busca sin salir de Git
Hay otro comando que desarrolladores y sysadmins suelen pasar por alto:
git grep "DATABASE_URL"
Busca un patrón dentro de los archivos rastreados por Git.
También se puede combinar con revisiones concretas:
git grep "old_server" HEAD~20
Viene de perlas para encontrar valores de configuración, nombres de funciones o referencias dentro del repositorio sin montar pipelines interminables de find y grep.
Cuando algo se rompe, Git puede ayudarte a encontrar cuándo pasó
5. git log: convierte el historial en algo legible
La versión básica funciona:
git log
Pero para entender ramas y merges suele venir mejor esto:
git log --oneline --graph --decorate --all
A partir de ahí Git empieza a parecerse menos a una lista de identificadores y más al historial real del proyecto.
También conviene conocer:
git log -p -- nginx.conf
Permite inspeccionar la evolución de un archivo concreto, algo muy útil cuando una configuración lleva años cambiando poco a poco.
6. git show: ¿qué hizo exactamente este commit?
Cuando aparece un commit sospechoso:
git show <commit>
Git muestra sus metadatos y sus cambios.
Es sencillo, pero combina de maravilla con log, blame, bisect y reflog.
7. git blame: averigua de dónde viene una línea
A pesar del nombre, blame sirve más para investigar que para señalar culpables.
git blame nginx.conf
Muestra qué commit modificó cada línea.
El siguiente paso suele ser:
git show <commit>
Así se entiende no solo quién introdujo una línea, sino qué otros cambios formaban parte de ese commit y por qué probablemente se hizo.
8. git bisect: encuentra el commit que rompió producción
Supongamos que la aplicación funcionaba bien en la versión v3.2.0, ahora está rota y entre medias hay 500 commits.
Revisarlos uno a uno no tiene ningún sentido.
git bisect start git bisect bad git bisect good v3.2.0
Git hace checkout de un commit más o menos a mitad de camino entre el estado bueno conocido y el malo. Lo pruebas y lo marcas:
git bisect good
o:
git bisect bad
Cada prueba reduce el espacio de búsqueda más o menos a la mitad, hasta dar con el commit problemático.
También se puede automatizar:
git bisect run ./test-regression.sh
Si un test puede determinar automáticamente si una versión está bien o mal, Git recorre el historial solo y localiza el primer commit que falla, sin que nadie tenga que intervenir a mano.
Recupera errores sin entrar en pánico
9. git restore: descarta cambios locales con claridad
Para recuperar la versión guardada en el commit de un archivo:
git restore app.conf
También se puede sacar un archivo del área de staging sin borrar sus modificaciones:
git restore --staged app.conf
El primer caso merece cuidado, restaurar un archivo puede descartar trabajo local que no está guardado en ningún otro sitio.
10. git stash: aparca trabajo sin terminar
Cuando aparece una incidencia urgente y tienes cambios a medias:
git stash
Luego puedes cambiar de rama y volver más tarde:
git stash pop
También se puede poner nombre a lo guardado:
git stash push -m "Cambios de configuración de PostgreSQL"
Y listar todo lo que hay guardado:
git stash list
No debería convertirse en almacenamiento permanente, pero para interrupciones cortas sigue siendo tremendamente útil.
11. git reflog: recupera lo que parecía perdido
Este es uno de los comandos que más cambia la forma de pensar sobre Git:
git reflog
El reflog registra las actualizaciones recientes de las referencias locales. Gracias a eso a veces se puede encontrar el estado anterior tras operaciones como un reset, un rebase o un movimiento de rama.
Una vez localizado el commit, se puede crear una rama de recuperación:
git switch -c recovery <commit>
Suele ser más seguro que lanzar más comandos reset sobre un repositorio que ya está hecho un lío.
12. git revert: deshaz sin reescribir historial compartido
reset y revert no son lo mismo.
Cuando un commit ya se ha publicado y otras personas pueden depender de él, esta opción suele ser preferible:
git revert <commit>
Git crea un commit nuevo que revierte los cambios del anterior.
Eso conserva el historial existente, algo que importa en ramas compartidas y en entornos donde la trazabilidad cuenta.
Trabaja mejor con ramas y tareas en paralelo
13. git switch: ramas sin sobrecargar checkout
Para crear una rama nueva y cambiarte a ella:
git switch -c fix/login-timeout
Para volver atrás:
git switch main
Y hay un atajo que viene bien:
git switch -
Vuelve a la rama anterior.
git checkout sigue funcionando, pero switch deja mucho más claro que la operación va de ramas.
14. git worktree: dos ramas abiertas a la vez
worktree merece bastante más atención de la que suele recibir, sobre todo ahora que los agentes de IA para programar están por todas partes.
Permite tener varios árboles de trabajo enlazados al mismo repositorio, cada uno con su propia rama.
Por ejemplo:
git worktree add ../hotfix fix/login-timeout
Puedes seguir trabajando en una funcionalidad en el directorio original mientras abres ../hotfix para resolver la incidencia.
Para listar los worktrees que hay:
git worktree list
Y cuando termines:
git worktree remove ../hotfix
Esto es especialmente útil cuando varios agentes de IA trabajan sobre el mismo proyecto. En vez de dejar que todos manipulen un único directorio, cada uno puede usar su propio worktree y su propia rama.
15. git cherry-pick: lleva un cambio concreto a otra rama
Se corrigió un bug en main, pero esa misma corrección también tiene que ir a una rama de mantenimiento estable.
No hace falta mergear todo:
git cherry-pick <commit>
Git aplica los cambios de ese commit y crea un commit equivalente en la rama actual.
Es especialmente útil para backports y para ramas de mantenimiento que viven mucho tiempo.
Limpia el historial sin convertirlo en un deporte de riesgo
16. git commit --fixup + rebase --autosquash
Supongamos que has creado este commit:
8d71a42 Fix authentication timeout
Luego descubres un problema pequeño relacionado. En vez de añadir otro commit llamado:
fix
puedes usar:
git commit --fixup 8d71a42
Más tarde:
git rebase -i --autosquash HEAD~6
Git reconoce los commits fixup! y los coloca junto al commit que están corrigiendo.
Es cómodo para trabajar con commits pequeños e incrementales durante el desarrollo y aun así presentar un historial limpio antes de mergear.
17. git range-diff: compara dos versiones de una serie de commits
Este comando se vuelve especialmente útil después de un rebase.
Un diff normal compara archivos. range-diff deja inspeccionar cómo ha cambiado una serie de commits respecto a otra.
Por ejemplo:
git range-diff main...feature-v1 main...feature-v2
Es útil en revisión de código cuando una rama se ha reescrito tras recibir feedback y quien revisa quiere entender qué cambió entre la primera versión y la segunda.
18. git rerere: deja que Git recuerde cómo resolviste un conflicto
El nombre viene de reuse recorded resolution.
Se activa así:
git config --global rerere.enabled true
Cuando aparece un conflicto, lo resuelves normalmente. Si Git se topa con el mismo conflicto más adelante, puede reutilizar la resolución que ya quedó guardada.
Es especialmente útil en ramas de larga duración, rebases repetidos y flujos de integración donde los mismos conflictos vuelven a aparecer una y otra vez.
Eso no elimina la necesidad de revisar el resultado. Solo evita resolver exactamente el mismo conflicto varias veces.
Tres comandos extra para repositorios grandes y equipos de operaciones
Sysadmins y equipos de plataforma pueden ir un paso más allá.
En monorepos muy grandes, sparse-checkout permite trabajar solo con parte del árbol:
git sparse-checkout init --cone git sparse-checkout set infrastructure ansible
También conviene conocer:
git fsck
que comprueba la conectividad y la validez de los objetos del repositorio, y:
git maintenance
que ejecuta tareas de mantenimiento pensadas para que los repositorios grandes sigan rindiendo bien.
No son comandos que necesites cada hora. Precisamente por eso mucha gente los descubre tarde.
El flujo de trabajo más útil no es el que tiene más comandos
Aprender Git no consiste en memorizar 50 comandos.
Un flujo de trabajo bastante más seguro puede empezar con algo tan sencillo como:
git status git diff git add -p git diff --staged git commit
Y luego, cuando hace falta, entran las herramientas más especializadas: bisect para encontrar una regresión, reflog cuando el trabajo parece perdido, worktree cuando hay tareas que necesitan correr en paralelo, y revert cuando hay que deshacer con seguridad un commit ya compartido.
Hay una diferencia que crece ahora que los agentes de IA para programar forman parte del flujo de trabajo diario. Herramientas como Claude Code, Codex, Gemini CLI y OpenCode pueden ejecutar comandos de Git muy rápido, así que entender qué hace realmente cada operación antes de darle permiso para ejecutarla importa cada vez más.
Un agente puede escribir git reset --hard en una fracción de segundo. Eso no significa que deba hacerlo.
Git resulta bastante menos intimidante en cuanto aprendes primero a inspeccionar el estado, después a modificarlo y por último a recuperarlo.
Ahí está probablemente la diferencia real entre usar Git como un sitio donde subir archivos y usarlo como una herramienta de ingeniería.
Preguntas frecuentes
¿Qué comandos de Git conviene aprender después de add, commit y push?
status, diff, add -p, log, show, restore y reflog son un buen siguiente paso. Después empiezan a resultar útiles comandos más especializados como bisect, worktree, rebase y cherry-pick.
¿Qué diferencia hay entre git revert y git reset?
git revert crea un commit nuevo que revierte un cambio anterior y suele ser la opción adecuada para historial compartido. reset mueve referencias y, según el modo que uses, también puede modificar el staging area y el directorio de trabajo.
¿Para qué sirve git worktree?
Permite tener varias ramas de un mismo repositorio en directorios distintos al mismo tiempo. Es útil para hotfixes, pruebas en paralelo y para separar el trabajo de varios agentes de código.
¿Se puede recuperar un commit borrado por error?
En algunas situaciones, sí. git reflog puede ayudar a localizar estados anteriores de las referencias y recuperar un commit que ya no aparece en el historial normal, siempre que los objetos de Git subyacentes sigan disponibles.
Imagen: Pexels / Daniil Komov