Antes pensaba que Git eran solo tres comandos:
Intento
git add .
git commit -m "update"
git push
Ese fue mi flujo de trabajo durante años.
Un día vi a un desarrollador senior recuperar commits eliminados, limpiar 6 meses de historial desordenado y deshacer una fusión mala sin buscar nada en Google y sin entrar en pánico. Mientras tanto, yo seguía buscando en Google: "cómo deshacer el último commit pero mantener los cambios" .
Ese fue el momento en que me di cuenta de algo: la mayoría de los desarrolladores conocen Git lo justo para sobrevivir. Los que se mueven rápido saben cómo funciona realmente. Aquí están los trucos y hábitos de Git que aprenderé demasiado tarde, los que realmente cambiaron mi forma de trabajar cada día.
Uso Git de forma incorrecta durante años
La respuesta corta es esta: los desarrolladores senior no son más rápidos en Git porque memorizan más comandos. Son más rápidos porque entienden Git como una línea temporal, un registro de todos los estados en los que ha existido tu proyecto. Una vez que eso encaja, cada comando empieza a tener sentido intuitivo.
Git no es solo control de versiones
Durante mucho tiempo traté Git como un simple sistema de respaldo: haz cambios, comprométete con un commit y empuja con un push. Pero Git es más bien una línea temporal de toda la vida de tu proyecto. Una vez que entendí eso, los comandos me dejaron darme miedo y corregir errores se volvió mucho más fácil.
Truco #1: git statuses el comando más importante
Esto suena obvio, pero lo ignoraré durante años. Ahora lo ejecuto constantemente antes de cada commit, antes de cambiar de rama y antes de volver a basear.
Intento
git status
La mayoría de los errores en Git ocurren cuando no conoces completamente tu estado actual. He metido en commits por error archivos .env, registros de depuración, código inacabado y capturas de pantalla aleatorias solo por saltarme este paso. Una orden que cuesta dos segundos te ahorra horas de dolores de cabeza.
Truco #2: git diffme salva de cometer embarazosos
Este truco cambió por completo mis compromisos. Antes de hacer un commit, ejecuto:
Intento
git diff
Esto me muestra exactamente qué cambió. He detectado claves API, importaciones rotas y declaraciones console.logsobrantes justo antes de pasar a producción.
Aún mejor:
Intento
git diff --staged
Solo muestra los archivos que ya añadiste al área de preparación. Ahora uso esto antes de casi cada compromiso.
Truco #3: Deja de usar git add .a ciegas
git add .lo monta todo. A veces está bien, pero a menudo solo quieres hacer un cambio específico, no las otras cuatro cosas que tocaste mientras trabajabas. Usa esto en su lugar:
Intento
git add -p
Esto te permite ir seleccionando los cambios poco a poco. Revisas cada fragmento y decide si lo pones en escena o lo saltas.
Ejemplo real: estaba trabajando en una corrección de inicio de sesión, un rediseño de la interfaz y una limpieza aleatoria, todo en el mismo archivo. Con git add -ppude subir solo la corrección de inicio de sesión de forma limpia. El resultado es un commit más ordenado y una depuración mucho más fácil después. Vale totalmente la pena perder esos 30 segundos extra.
Truco #4: git bisectte hace sentir como una maga
Ignoré esta orden durante años porque me parecía demasiado avanzada.
Imagínate la situación: sabes que algo está roto en producción. Sabe que funcionó hace tres semanas, pero no tiene ni idea de cuál de los 80 compromisos intermedios introdujo el problema.
Intento
git bisect start
git bisect bad # El estado current está roto
git bisect good v2.3.1 # Esta versión estaba bien
Git entonces revisa el commit exactamente a medio camino entre lo bueno y lo malo. Pruébalo y dile a Git si ese estado es bueno o malo. El sistema volverá a reducir el espacio de búsqueda a la mitad. Repite este proceso unas 7 veces y reducirás esos 80 cometes a uno solo.
Hace poco usé esto con un error que llevaba abierto un mes. Encuentre el compromiso exacto en una vez minutos. El mensaje de compromiso decía "limpieza menor". Spoiler: no fue una limpieza menor.
Truco #5: git stashes un salvavidas
Este comando me ha salvado más veces de las que puedo contar.
La situación: vas a la mitad de una funcionalidad importante y de repente aparece un error urgente. Tienes que cambiar de rama ahora mismo. Antes de conocer este truco, me ponía súper nervioso. Ahora simplemente hago:
Intento
git stash
Tu trabajo desaparece en una taquilla segura. Cambias de rama, arreglas el bug, vuelves a tu rama original y ejecutas:
Intento
git stash pop
Todo vuelve exactamente al estado en que lo dejaste. Las ramas son básicamente entornos sandbox, y git stashes la pausa de emergencia entre ellas.
Truco #6: Por fin entendígit log
Durante años, el historial de Git me parecía puro ruido. Entonces empecé a usar:
Intento
git log --oneline --graph --decorate
De repente, toda la línea temporal del proyecto se volvió visible: ramas, fusiones, flujo de commits... todo expuesto con total claridad. Creé un alias inmediatamente:
Intento
alias gl='git log --oneline --graph --decorate'
Ahora gles uno de los comandos que más utilizo en mi flujo de trabajo diario.
(Si aún no te sientes cómodo con los alias, o la configuración de tu terminal sigue siendo la predeterminada, escribí un post aparte sobre trucos de terminal que cubre este tema: "Usé el terminal mal durante años" y "Qué hacen los desarrolladores senior de forma diferente en la terminal" en medium.com. Merece la pena leerlos junto con este).
Truco #7: Las ramas son baratas — úsalas más
Trabajar directamente en la rama maines una trampa; Yo lo hice durante demasiado tiempo. Ahora creo ramas para casi todo:
Intento
git switch -c fix-login-bug
Esto cambió mi forma de experimentar sin miedo. Puedo probar ideas, refactorizar de forma agresiva y probar soluciones arriesgadas sin tocar nunca el código estable. Básicamente es como un cd -pero para las ramas de Git. Las ramas son gratuitas; el costo de romper producción no lo es.
Truco #8: Aprende a usar git restoreantes de necesitarlo
Esta orden me salvó de un infarto. Imagina que editas accidentalmente el archivo equivocado. En lugar de deshacer los cambios manualmente, ejecute:
Intento
git restore app.js
Y listo: el archivo se restaura a su último estado confirmado al instante. Ojalá hubiera aprendido esto en mi primer mes.
Truco #9: git worktreeestá criminalmente infravalorado
Este tema salió en un hilo de Reddit titulado "Opinión polémica: los árboles de trabajo están infravalorados" y fui a leerlo entero. La opinión polémica tenía toda la razón. Normalmente, al cambiar de tarea a mitad de un desarrollo, solía hacer un ciclo eterno de guardar en stash, cambiar de rama, hacer el fix, volver a la rama anterior, sacar del stash y rezar para que nada entrara en conflicto.
git worktreefunciona de forma diferente:
Intento
git worktree add ../hotfix-branch hotfix/login-timeout
Esto te descarga la rama en un directorio separado ( hotfix/login-timeout). Tu rama actual permanece intacta. Simplemente vas al otro directorio con un cd, arreglas el error, haces el push y luego vuelves a tu funcionalidad original.
Nada de esconder cambios, nada de salirte de donde estabas y nada de decir "ay Dios, ¿en qué punto estaba trabajando?" . Seré sincera: todavía no recurro a este comando de forma automática porque me resulta un poco desconocido, pero para interrupciones más largas (de una hora o más), es muchísimo más limpio que el flujo de trabajo de guardar y rezar.
Truco #10: git reflogse siente como un viaje en el tiempo
Este es el comando que hace que los desarrolladores senior parezcan mágicos. Una vez pensé que había perdido comete permanentemente durante un rebase. Esto es lo que la mayoría de los desarrolladores no saben: Git lo recuerda casi todo.
Intento
git reflog
Muestra todas tus acciones recientes en Git, incluso los commits que creías haber eliminado, las ramas que perdiste y los estados por los que ha pasado tras un reset. La recuperación se hace con una sola orden:
Intento
git checkout <commit-id>
Ese momento cambió por completo mi forma de pensar sobre los errores en Git. Ahora tengo mucho menos miedo de equivocarme. git refloges tu red de seguridad y guarda la información durante unos 90 días después de cada acción. Úsalo antes de asumir que algo ha desaparecido para siempre.
Truco #11: Escribir mejores mensajes de commit importa más de lo que crees
Mi "yo" de antes hacía cosas como:
Intento
git commit -m "fix"
Mi "yo" del futuro odiaba a ese tipo. Ahora escribe:
Intento
git commit -m "Fix token refresh issue in auth middleware"
Los buenos mensajes de commit no son para Git; son para los humanos. son para tu propio "yo" del futuro dentro de seis meses, intentando entender por qué cambió una línea de código a las 11 de la noche de un jueves.
Truco #12: La rebase interactiva ha limpiado mi historial
EVité git rebasedurante años porque parecía peligroso. Entonces aprenderé a usarlo así:
Intento
git rebase -i HEAD~5
Esto te permite aplastar (squash) los commits, renombrarlos y reordenarlos todos antes de enviar un Pull Request (PR).
- Antes:
fix,another fix,small update,final fix. - Después:
Improve authentication error handling.
Un compromiso limpio y significativo. Tus compañeros de equipo notarán la diferencia, te lo aseguro.
Truco #13: git blamees sorprendentemente útil
A pesar de su nombre tan aterrador ( "echar la culpa" ), es una maravilla:
Intento
git blame app.js
Muestra quién cambió cada línea, cuándo y en qué se hizo el commit. He usado esto para rastrear errores de producción hasta el commit exacto que los introducidos, para entender por qué existe un fragmento de código extraño y para encontrar commits relacionados que no sabía que estaban conectados. Básicamente es hacer arqueología de código, y es sorprendentemente satisfactorio cuando encuentras lo que buscas.
Truco #14: Los alias eliminan la fricción
Me cansé de escribir comandos largos, así que añadí alias a mi configuración:
Intento
alias gs='git status'
alias ga='git add'
alias gc='git commit -m'
alias gp='git push'
alias gl='git log --oneline --graph --decorate'
Cada alias te ahorras quizás unos 3 segundos. En 50 usos diarios a lo largo de los meses, eso suma muchísimo. Y lo que es más importante: una menor fricción significa que realmente vas a ejecutar los comandos que deberías ejecutar.
El verdadero cambio
Durante años, pensé que tener buenas habilidades en Git significaba memorizar órdenes de memoria. Ahora creo que se trata principalmente de mantener la calma cuando las cosas van mal.
Los mejores desarrolladores que conozco no le temen a Git porque entienden cómo recuperarse de los errores. Esa es la verdadera diferencia. No es escribir más rápido ni usar flujos de trabajo súper deseados; es una cuestión de confianza .
Y, sinceramente, la mayor parte de la confianza en Git viene de aprender tres cosas básicas:
- Cómo inspeccionar cambios
- Cómo deshacer errores
- Cómo recuperarse de forma segura
Una vez que sabes esas cosas, Git deja de sentirte peligroso. Empieza poco a poco con estos tres comandos: git diff, git stashy git reflog. Solo con ellos te aseguro que te vas a ahorrar horas de trabajo incontables.
Gracias por leer Código en Casa.
Si esto te a ayudado y te sumo algo Dale un 👏 , compártelo con tu red o dejame un comentario para saber tu opinión.
