18 comandos de Git que todo desarrollador y sysadmin debería conocer

Muchos profesionales empiezan utilizando Git con tres instrucciones: git add ., git commit y git push. Es suficiente hasta que aparece el primer merge problemático, se elimina una rama por error, hay que localizar qué cambio rompió producción o dos tareas urgentes necesitan trabajar simultáneamente sobre el mismo repositorio. Ahí Git deja de ser simplemente el lugar donde guardar código y empieza a demostrar para qué fue diseñado realmente.

Las claves de Git para desarrolladores y sysadmins en 30 segundos

• Git permite inspeccionar, comparar y recuperar estados del proyecto, no solo guardar versiones.
• git add -p, git diff y git status ayudan a evitar commits accidentales antes de que lleguen al repositorio.
• bisect puede localizar mediante búsqueda binaria el commit que introdujo un fallo.
• reflog permite recuperar referencias que parecían perdidas tras un reset o un rebase.
• worktree, range-diff, rerere y fixup resultan especialmente útiles en flujos de trabajo más avanzados.

El cambio importante llega cuando se entiende que los commits forman un historial enlazado y que ramas, etiquetas y HEAD son referencias a determinados puntos de ese historial. Buena parte de los comandos que inicialmente parecen difíciles empiezan entonces a tener sentido.

Además, Git ha evolucionado. Las versiones actuales mantienen checkout, pero ofrecen comandos como switch y restore para separar operaciones que históricamente estaban concentradas en una misma instrucción. La documentación oficial de Git 2.55, publicada en junio de 2026, mantiene ambos enfoques.

Estos son 18 comandos y combinaciones que merece la pena incorporar al trabajo diario, incluidos algunos especialmente interesantes para administradores de sistemas y equipos que mantienen repositorios grandes.

Antes de modificar el historial: mirar qué está pasando

1. git status: dos segundos que evitan muchos problemas

Puede parecer demasiado básico para encabezar una lista avanzada, pero sigue siendo una de las mejores costumbres antes de realizar cambios importantes.

git status

Permite comprobar la rama actual, modificaciones pendientes, archivos preparados para commit y archivos todavía no seguidos.

Especialmente antes de un commit, rebase, cambio de rama o despliegue, saber exactamente dónde se encuentra el repositorio evita trabajar sobre una suposición equivocada.

2. git diff: revisar antes de enviar

Para ver los cambios todavía no añadidos al área de preparación:

git diff

Y para revisar exactamente lo que entrará en el siguiente commit:

git diff --staged

Este último debería formar parte de la rutina de cualquier equipo. Puede descubrir desde un console.log olvidado hasta una contraseña, un token, una modificación de configuración o simplemente código que pertenecía a otra tarea.

3. git add -p: dejar de añadirlo todo

Uno de los hábitos que merece la pena abandonar es utilizar siempre:

git add .

Git dispone de selección interactiva:

git add -p

En lugar de preparar automáticamente todas las modificaciones, presenta los cambios por fragmentos y permite decidir cuáles deben entrar en el commit.

Es especialmente práctico cuando un mismo archivo contiene una corrección urgente y cambios correspondientes a otro desarrollo.

El resultado son commits más pequeños y comprensibles.

4. git grep: buscar sin salir de Git

Para desarrolladores y sysadmins existe otro comando que pasa bastante desapercibido:

git grep "DATABASE_URL"Lenguaje del código: JavaScript (javascript)

Busca un patrón dentro de los archivos gestionados por Git. También puede combinarse con revisiones:

git grep "old_server" HEAD~20Lenguaje del código: JavaScript (javascript)

Resulta práctico para localizar configuraciones, nombres de funciones o referencias dentro del repositorio sin construir comandos más largos con find y grep.

Cuando algo se rompe, Git puede ayudar a encontrar cuándo ocurrió

5. git log: convertir el historial en algo legible

La versión básica funciona:

git log

Pero para comprender ramas y merges suele ser más útil:

git log --oneline --graph --decorate --all

Aquí Git empieza a parecer menos una sucesión de identificadores y más el historial real del proyecto.

También merece la pena conocer:

git log -p -- nginx.confLenguaje del código: CSS (css)

Permite estudiar los cambios realizados sobre un archivo concreto, algo especialmente útil cuando una configuración lleva años evolucionando.

6. git show: qué hizo exactamente este commit

Cuando aparece un commit sospechoso:

git show <commit>Lenguaje del código: HTML, XML (xml)

Git muestra sus metadatos y cambios.

Es una herramienta sencilla, pero combina muy bien con log, blame, bisect y reflog.

7. git blame: averiguar de dónde salió una línea

Pese a su nombre, blame resulta más útil para investigar que para buscar culpables.

git blame nginx.confLenguaje del código: CSS (css)

Permite saber qué commit modificó cada línea.

El siguiente paso debería ser normalmente:

git show <commit>Lenguaje del código: HTML, XML (xml)

Así puede entenderse no solamente quién introdujo una línea, sino qué otros cambios formaban parte de aquella modificación y por qué pudo hacerse.

8. git bisect: encontrar el commit que rompió producción

Supongamos que una aplicación funcionaba correctamente en la versión v3.2.0, ahora falla y existen 500 commits entre ambos estados.

Revisarlos uno por uno sería absurdo.

git bisect start
git bisect bad
git bisect good v3.2.0Lenguaje del código: CSS (css)

Git selecciona un punto intermedio. El usuario comprueba esa versión y la marca:

git bisect good

o:

git bisect bad

Cada prueba reduce aproximadamente a la mitad el espacio de búsqueda hasta localizar el cambio responsable.

Lo interesante es que puede automatizarse:

git bisect run ./test-regression.sh

Si existe una prueba capaz de determinar automáticamente si una versión funciona, Git puede recorrer el historial y localizar el primer commit problemático sin necesidad de comprobar manualmente cada paso.

Recuperar errores sin entrar en pánico

9. git restore: descartar cambios locales con claridad

Para recuperar la versión registrada de un archivo:

git restore app.confLenguaje del código: CSS (css)

También puede retirarse un archivo del área de preparación sin eliminar sus modificaciones:

git restore --staged app.confLenguaje del código: CSS (css)

Conviene prestar atención al primer caso: restaurar un archivo puede descartar modificaciones locales que todavía no se habían guardado.

10. git stash: aparcar cambios temporalmente

Cuando llega una incidencia urgente mientras existe trabajo sin terminar:

git stash

Después puede cambiarse de rama y regresar más tarde:

git stash pop

También es posible poner nombre al trabajo guardado:

git stash push -m "cambio configuración PostgreSQL"Lenguaje del código: JavaScript (javascript)

Y consultar todos los elementos:

git stash listLenguaje del código: PHP (php)

No debería convertirse en un almacén permanente, pero para interrupciones breves sigue siendo muy práctico.

11. git reflog: recuperar lo que parecía perdido

Este es uno de los comandos que más cambia la percepción sobre Git:

git reflog

El reflog registra las actualizaciones de referencias realizadas en el repositorio local. Esto puede permitir encontrar estados anteriores después de determinadas operaciones como un reset, un rebase o movimientos de ramas.

Una vez localizado el commit puede crearse una rama de recuperación:

git switch -c recovery <commit>Lenguaje del código: HTML, XML (xml)

Es más prudente que empezar a ejecutar nuevos reset sobre un repositorio que ya se encuentra en una situación confusa.

12. git revert: deshacer sin reescribir el historial compartido

reset y revert no son equivalentes.

Cuando un commit ya se ha publicado y otras personas pueden estar trabajando sobre él, suele interesar:

git revert <commit>Lenguaje del código: HTML, XML (xml)

Crea un nuevo commit que revierte los cambios del anterior.

Esto conserva la historia existente, algo especialmente valioso en ramas compartidas y entornos donde importa mantener trazabilidad.

Trabajar mejor con ramas y tareas paralelas

13. git switch: ramas sin sobrecargar checkout

Para crear y cambiar a una nueva rama:

git switch -c fix/login-timeoutLenguaje del código: JavaScript (javascript)

Para volver:

git switch mainLenguaje del código: JavaScript (javascript)

Y existe un pequeño atajo especialmente cómodo:

git switch -Lenguaje del código: JavaScript (javascript)

Regresa a la rama anterior.

git checkout continúa funcionando, pero switch deja más claro que la operación afecta a ramas. La documentación oficial confirma además que Git protege los cambios locales cuando un cambio de rama pudiera provocar su pérdida.

14. git worktree: dos ramas abiertas al mismo tiempo

worktree merece mucha más atención con la llegada de los agentes de programación.

Permite tener varios árboles de trabajo vinculados al mismo repositorio, cada uno con una rama diferente.

Por ejemplo:

git worktree add ../hotfix fix/login-timeout

El desarrollador puede continuar trabajando en una funcionalidad en el directorio original mientras abre ../hotfix para resolver la incidencia.

Para consultar los existentes:

git worktree listLenguaje del código: PHP (php)

Y al terminar:

git worktree remove ../hotfix

Esto resulta especialmente interesante cuando trabajan simultáneamente varios agentes de IA sobre un proyecto. En lugar de hacer que todos manipulen el mismo directorio, pueden utilizarse diferentes worktrees y ramas.

15. git cherry-pick: llevar un cambio concreto a otra rama

Un bug se ha solucionado en main, pero la corrección también debe incorporarse a una rama estable.

No hace falta fusionar todos los cambios:

git cherry-pick <commit>Lenguaje del código: HTML, XML (xml)

Git aplica los cambios introducidos por ese commit y crea el correspondiente commit en la rama actual. La documentación también contempla --continue, --skip y --abort cuando aparecen conflictos durante el proceso.

Es particularmente útil para backports y ramas de mantenimiento.

Limpiar el historial sin convertirlo en un deporte de riesgo

16. git commit --fixup + rebase --autosquash

Supongamos que se ha creado un commit:

8d71a42 Fix authentication timeout

Después aparece un pequeño error relacionado. En lugar de añadir:

fix

puede utilizarse:

git commit --fixup 8d71a42

Y posteriormente:

git rebase -i --autosquash HEAD~6

Git reconoce los commits fixup! y los coloca junto al commit que deben corregir. Es una función soportada directamente por git commit y rebase, no una convención improvisada por determinadas plataformas.

Resulta muy cómoda para trabajar con commits pequeños durante el desarrollo y presentar después una historia limpia antes de fusionar una rama.

17. git range-diff: comparar dos versiones de una serie de commits

Este comando es especialmente interesante después de un rebase.

Una comparación convencional muestra archivos. range-diff permite estudiar cómo ha cambiado una serie de commits respecto a otra.

Por ejemplo:

git range-diff main...feature-v1 main...feature-v2Lenguaje del código: CSS (css)

Puede ser muy útil durante la revisión de código cuando una rama ha sido modificada después de recibir comentarios: permite identificar qué ha cambiado entre la primera y la segunda versión de la serie.

La propia documentación de Git incluye range-diff entre sus herramientas de inspección y comparación.

18. git rerere: que Git recuerde cómo resolviste un conflicto

El nombre procede de reuse recorded resolution.

Se activa con:

git config --global rerere.enabled trueLenguaje del código: PHP (php)

Cuando aparece un conflicto, el usuario lo resuelve normalmente. Si Git encuentra posteriormente el mismo conflicto, puede reutilizar la resolución registrada.

Es especialmente útil en ramas que se reorganizan repetidamente, procesos largos de integración o rebases donde vuelven a aparecer conflictos conocidos.

No elimina la necesidad de revisar el resultado. Evita tener que solucionar manualmente exactamente el mismo problema una y otra vez.

Tres comandos adicionales para repositorios grandes y operaciones

Los sysadmins y equipos de plataforma pueden ir todavía algo más lejos.

En monorepos enormes, sparse-checkout permite trabajar únicamente con una parte del árbol:

git sparse-checkout init --cone
git sparse-checkout set infrastructure ansibleLenguaje del código: JavaScript (javascript)

Git mantiene soporte específico para este modo de trabajo y documenta qué comandos operan sobre el conjunto reducido y cuáles continúan trabajando sobre el repositorio completo.

También merece la pena conocer:

git fsck

para comprobar conectividad y validez de objetos del repositorio, y:

git maintenance

para las tareas de mantenimiento destinadas a conservar un rendimiento adecuado, especialmente en repositorios grandes.

No son comandos que haya que ejecutar constantemente. Precisamente por eso suelen descubrirse demasiado tarde.

El Git más útil no es el que tiene más comandos

Aprender Git no consiste en memorizar cincuenta instrucciones.

Un flujo bastante más seguro puede comenzar simplemente así:

git status
git diff
git add -p
git diff --staged
git commit

Después aparecen las herramientas que resuelven problemas concretos: bisect cuando hay que encontrar una regresión, reflog cuando parece haberse perdido trabajo, worktree cuando hay tareas paralelas y revert cuando debe deshacerse un cambio que ya forma parte de un historial compartido.

También hay una diferencia cada vez más importante con los agentes de programación. Herramientas como Claude Code, Codex, Gemini CLI u OpenCode pueden ejecutar Git con mucha rapidez. Eso hace todavía más necesario entender qué significa cada operación antes de conceder permisos para ejecutarla.

Un agente puede escribir git reset --hard en una fracción de segundo. Que pueda hacerlo no significa que deba hacerlo.

Git resulta mucho menos intimidante cuando se aprende primero cómo inspeccionar el estado, después cómo modificarlo y finalmente cómo recuperarlo.

Ahí está probablemente la diferencia entre utilizar Git como un sitio donde subir archivos y utilizarlo como una herramienta de ingeniería.

Preguntas frecuentes

¿Qué comandos de Git debería aprender después de add, commit y push?

status, diff, add -p, log, show, restore y reflog forman una buena segunda etapa. Después pueden incorporarse herramientas más específicas como bisect, worktree, rebase y cherry-pick.

¿Qué diferencia hay entre git revert y git reset?

git revert crea un nuevo commit que deshace otro cambio y resulta adecuado para historiales compartidos. reset mueve referencias y, dependiendo del modo utilizado, también puede modificar el índice y el árbol de trabajo.

¿Para qué sirve git worktree?

Permite tener varias ramas del mismo repositorio abiertas simultáneamente en directorios diferentes. Es útil para hotfixes, pruebas paralelas y también para separar el trabajo de varios agentes de programación.

¿Se puede recuperar un commit borrado por error?

En determinadas situaciones sí. git reflog puede permitir localizar estados anteriores de referencias y recuperar un commit que ya no aparece en el historial normal, siempre que sus objetos sigan disponibles.