Git Commands Cheat Sheet: The 20 Commands You Actually Use — txt1.ai

La Crisis de Producción a las 3 AM Que Cambió Cómo Pienso Sobre Git

Nunca olvidaré la noche en que toda nuestra tubería de despliegue falló a las 3 AM. Era un ingeniero DevOps senior en una startup fintech, llevaba cinco años en mi carrera, y acababa de recibir una alerta porque alguien había hecho un "force push" a main y había borrado tres días de trabajo de cuatro equipos diferentes. Mis manos temblaban mientras miraba mi terminal, sabiendo que cada segundo contaba—teníamos plazos regulatorios, partes interesadas enojadas y un equipo de desarrolladores exhaustos esperando que solucionara esto.

Fue entonces cuando me di cuenta de algo crucial: había estado usando Git durante medio decenio, pero solo realmente conocía unas 20 órdenes. Todo lo demás era ruido. La documentación de Git enumera más de 160 comandos, pero en ese momento de crisis, busqué las mismas herramientas que había usado miles de veces antes. ¿Y sabes qué? Fueron suficientes. Nos salvaron esa noche.

Desde entonces, he trabajado con más de 200 desarrolladores en tres compañías, he realizado innumerables revisiones de código y he rescatado más repositorios de los que puedo contar. He rastreado mi uso real de Git durante los últimos dos años usando análisis de historial de shell, y los datos son sorprendentes: el 94% de mis interacciones con Git involucran solo 20 comandos. El 6% restante se divide entre docenas de operaciones obscuras que podría usar una vez por trimestre.

Este artículo no es otra referencia exhaustiva de Git que marcarás como favorita y nunca leerás. Esta es la lista de comandos probada en batalla y demostrada en producción que manejará el 99% de tu trabajo diario. Te voy a mostrar exactamente cómo uso cada uno, las banderas que realmente importan y los modelos mentales que me han mantenido cuerdo a través de cientos de conflictos de fusión y emergencias de despliegue.

La Base: Comandos Que Usarás Todos los Días

Comencemos con lo absolutamente esencial—los comandos que uso tan frecuentemente que mis dedos los escriben sin pensar. Estos cinco comandos forman la columna vertebral de cada flujo de trabajo de Git, y si no dominas nada más, domina estos.

Después de analizar dos años de historial de shell en mi equipo, descubrí algo contraintuitivo: los desarrolladores que conocían menos comandos de Git a menudo eran más productivos. Dominaron los 20 esenciales y podían ejecutarlos sin pensar, mientras que aquellos que memorizaron todo el manual pasaban preciosos segundos deliberando entre opciones similares durante momentos críticos.

git status es mi compañero constante. Corro este comando probablemente 50 veces al día, y no estoy exagerando. Antes de cada commit, después de cada pull, siempre que estoy confundido sobre lo que está sucediendo—git status es mi primer movimiento. Te muestra qué archivos están preparados, cuáles están modificados pero no listos, y cuáles no están rastreados. La salida está codificada por colores y es increíblemente legible. He visto a desarrolladores junior luchar durante horas con problemas de Git que habrían sido inmediatamente evidentes si simplemente hubieran ejecutado git status.

Este es mi flujo de trabajo: Escribo git status tan a menudo que lo he aliasado como "gs" en mi configuración de shell. Cada vez que cambio de contexto o regreso de una reunión, git status es cómo recuerdo en qué estaba trabajando. Es como un marcador para tu estado actual.

git add es cómo preparas cambios para el commit. El patrón más común es git add . que prepara todo en tu directorio actual, pero en realidad recomiendo no usar esto sin pensar. En su lugar, uso git add -p (modo de parche) para aproximadamente el 60% de mis commits. Esto te permite revisar cada cambio de forma interactiva y preparar solo los bloques que desees. Es más lento, sí, pero me ha salvado de cometer código de depuración, claves API y declaraciones console.log vergonzosas más veces de las que puedo contar.

Para trabajo rápido, git add filename prepara un archivo específico. Uso esto cuando tengo confianza en lo que estoy cometiendo. La clave aquí es que la preparación es separada del commit—puedes preparar archivos de forma incremental, revisarlos con git status, y luego cometer cuando estés listo.

git commit crea una instantánea de tus cambios preparados. Uso git commit -m "mensaje" para cambios pequeños y obvios, pero para cualquier cosa sustancial, simplemente escribo git commit y dejo que se abra mi editor. Esto me obliga a escribir un mensaje de commit adecuado con una línea de asunto y cuerpo. Buenos mensajes de commit son documentación para tu yo futuro. He pasado incontables horas buscando en el historial de git tratando de entender por qué se realizó un cambio, y los mensajes de commit detallados valen su peso en oro.

Mi plantilla de mensajes de commit: la primera línea es un resumen conciso (50 caracteres o menos), luego una línea en blanco, después una explicación detallada de qué cambió y por qué. El "por qué" es crucial—el diff muestra qué cambió, pero solo tú puedes explicar la razón.

git push envía tus commits al repositorio remoto. La mayoría de las veces, git push es todo lo que necesitas. Si estás empujando una nueva rama por primera vez, necesitarás git push -u origin branch-name para configurar el seguimiento. La bandera -u (abreviatura de --set-upstream) significa que los futuros push y pull en esta rama no requerirán que especifiques el remoto y el nombre de la rama.

Una bandera crítica que debes conocer: git push --force-with-lease. Nunca, jamás uses git push --force a menos que estés absolutamente seguro de que quieres sobrescribir el historial remoto. La variante --force-with-lease es más segura porque falla si otra persona ha enviado commits que no tienes localmente. He visto que --force borra el trabajo de equipos enteros. No seas esa persona.

git pull obtiene cambios del remoto y los fusiona en tu rama actual. Lo ejecuto cada mañana antes de comenzar a trabajar y antes de cada push. El comportamiento predeterminado está bien en la mayoría de los casos, pero prefiero git pull --rebase porque mantiene la historia más limpia al evitar commits de fusión innecesarios. He configurado esto como mi predeterminado con git config --global pull.rebase true.

Ramificación: Tu Caja de Herramientas de Universo Paralelo

Las ramas son donde reside el verdadero poder de Git. Te permiten trabajar en características, experimentos y correcciones en aislamiento sin afectar la base de código principal. Probablemente creo de 10 a 15 ramas por semana, y estos comandos hacen que ese flujo de trabajo sea fluido.

git branch lista todas tus ramas locales. La rama actual está marcada con un asterisco. Uso git branch -a para ver ramas remotas también, y git branch -d branch-name para eliminar ramas con las que he terminado. La bandera -d es segura—no te permitirá eliminar una rama con cambios no fusionados. Si estás absolutamente seguro de que quieres eliminar una rama (quizás fue un experimento que falló), usa git branch -D branch-name.

Limpio viejas ramas religiosamente. Un repositorio con 50 ramas obsoletas es confuso y hace difícil encontrar lo que buscas. Cada viernes, corro git branch --merged para ver qué ramas han sido fusionadas en main, y luego las elimino. Es como limpiar tu escritorio—simplemente se siente bien.

git checkout cambia entre