Los 20 Comandos Git Básicos Que Usás Todos los Días

En pocas palabras: Con veinte comandos de Git cubrís el trabajo diario: status, add, commit, branch, switch, merge, push, pull y fetch forman el noventa por ciento del flujo real, según el cheat sheet de dev.to basado en la documentación oficial de git-scm.com.

Los comandos git básicos que usás todos los días son apenas veinte, no cien. Según el cheat sheet publicado en dev.to, con status, add, commit, branch, push y pull cubrís el noventa por ciento del trabajo real en cualquier repositorio, desde el primer commit hasta el día que subís algo a producción.

Git es un sistema de control de versiones distribuido y gratuito que guarda el historial completo de un proyecto en forma de snapshots llamados commits. Según la documentación oficial de git-scm.com, cada desarrollador tiene una copia completa de esa historia en su propia máquina, lo que permite trabajar offline a máxima velocidad y sincronizar los cambios después con un repositorio remoto como GitHub.

¿Qué hace Git en la práctica (y por qué es distribuido)?

Git guarda cada cambio de tu proyecto como una fotografía llamada commit, y cada commit recuerda al anterior, armando una cadena que es la historia completa de tu código. Según la propia documentación de git-scm.com, Git es un sistema de control de versiones distribuido y gratuito, pensado para manejar desde proyectos chicos hasta repositorios enormes con velocidad.

¿Qué significa “distribuido” en términos concretos? Que cada desarrollador tiene una copia completa de la historia en su máquina, no solo los últimos cambios. Podés hacer commits, revisar logs y comparar versiones sin conexión a internet, y recién cuando estás listo subís todo al servidor compartido.

Nada se pierde en el camino. Podés volver a cualquier snapshot anterior cuando quieras.

Ponele que estás armando un formulario de contacto, probás algo, no funciona, y querés volver a como estaba hace diez minutos. Con Git, eso es un comando, no una reconstrucción de memoria a las apuradas.

Configuración inicial: git config, git init y git clone

Antes de tocar cualquier otro comando, Git necesita saber quién sos. Eso se hace una sola vez por máquina con git config --global user.name y git config --global user.email. Después, según si estás arrancando un proyecto de cero o sumándote a uno existente, usás git init o git clone.

• git config –global user.name “Tu Nombre”: firma tus commits con tu nombre, una vez por computadora.
• git config –global user.email “[email protected]”: hace lo mismo con tu email, para que cada commit quede atribuido.
• git init: convierte la carpeta actual en un repositorio nuevo, para proyectos que arrancás de cero.
• git clone https://github.com/usuario/proyecto.git: descarga un proyecto existente con toda su historia, para sumarte a algo que ya existe.

La diferencia es simple: si arrancás vos el proyecto, usás init. Si te sumás a uno que ya existe en GitHub, usás clone. No hay mucho más misterio ahí. Cubrimos ese tema en detalle en el benchmark entre Mac mini M6 y runners macOS.

El ciclo diario: los comandos git básicos que vas a usar más (status, add, commit, diff)

git status es el comando que vas a tipear más seguido en tu vida como developer: te muestra qué archivos cambiaron, cuáles están en staging y en qué rama estás parado. Es, literalmente, el tablero de control de Git.

git add mueve cambios a la zona de staging, la sala de espera antes del commit. Podés agregar un archivo puntual con git add index.html, o todo de una con git add ., aunque esto último conviene revisarlo antes con un status rápido para que no se cuele algo que no querías subir.

git commit -m "mensaje" guarda esa foto con una descripción corta. Y acá va la parte que nadie respeta: escribí mensajes que digan qué o por qué cambiaste algo, tipo “Arreglar botón de login en mobile”, no “cambios” o “final final v2” (sí, en serio, todavía se ven commits así).

git diff te muestra, línea por línea, lo que todavía no subiste a staging. git diff --staged muestra exactamente lo que va a entrar en el próximo commit. Revisar el diff antes de confirmar es el hábito que te salva de commits vergonzosos.

¿Cómo revisar el historial con git log y git show?

git log lista tus commits del más nuevo al más viejo, con autor, fecha y mensaje. Con git log --oneline comprimís cada commit a una sola línea, ideal para tener una vista rápida sin scrollear diez pantallas.

git show HEAD abre el último commit y muestra exactamente qué cambió ahí adentro. Si querés ver uno anterior, pegás el código corto que te dio el log, por ejemplo git show a1b2c3d. Ya lo cubrimos antes en cómo se comparan las plataformas de CI/CD en 2026.

La historia no es decoración. ¿Para qué sirve en serio? Responde las dos preguntas que todo developer se hace cada semana: cuándo cambió esto y qué cambió exactamente.

¿Cómo se trabaja con ramas usando branch, switch y merge?

Una rama en Git es una etiqueta que apunta a un commit, una línea de trabajo separada donde podés probar cosas sin tocar la rama principal. git branch lista las que tenés, git switch te mueve a una, y git switch -c nombre-rama crea y te mueve en un solo paso.

Cuando terminás el trabajo en esa rama, volvés a main y corrés git merge nombre-rama para traer esos commits a la línea principal. Así de simple: creás, trabajás, fusionás.

Ponele que estás armando una página de login nueva. En vez de tocar directamente main y arriesgarte a romper lo que ya funciona en producción, abrís una rama con git switch -c nueva-pagina-login, trabajás tranquilo ahí, y recién cuando está probado la mergeás a la rama principal.

¿Cuál es la diferencia entre git fetch y git pull para sincronizar con el remoto?

La diferencia es que git pull descarga y fusiona de inmediato en tu rama actual, mientras que git fetch solo descarga y te deja revisar antes de mezclar nada. Un remoto es la dirección de otra copia de tu repositorio, generalmente en GitHub, y origin es el nombre estándar que le ponés al principal.

git remote -v te muestra cuáles tenés configurados. git push origin main sube tus commits al remoto. git fetch, según lo describe el propio cheat sheet, es la prima cautelosa de pull: baja los cambios pero no los toca hasta que vos decidís. Lo explicamos a fondo en cuál conviene elegir entre Jenkins y GitHub Actions.

¿Y si hacés pull directo sin mirar nada? Puede andar bien casi siempre, pero cuando hay conflictos te explota justo cuando tenés menos tiempo para resolverlo.

¿Cómo deshago cambios sin romper nada con restore y commit –amend?

git restore archivo.html descarta cambios no confirmados en ese archivo puntual, y no hay forma de recuperarlos después. Usalo solo cuando estés seguro de que ese trabajo no sirve. Con la bandera --staged, en cambio, solo saca el archivo del staging sin tocar tus ediciones.

git commit --amend -m "mejor mensaje" reescribe tu último commit, perfecto para corregir un typo o sumar un archivo olvidado. Ojo con esto: funciona bien antes de hacer push. Una vez que ese commit ya está en el remoto y lo compartiste con el equipo, reescribirlo es meterte con la historia de otros, y ahí sí se arma lío.

La regla es simple. Historia propia y sin pushear: la podés tocar. Historia compartida: no la toqués.

Un día normal de trabajo usando solo estos 20 comandos

Un día típico con Git arranca con git pull para traer lo último del equipo, sigue con git switch -c para abrir una rama nueva, y termina con git merge y git push antes de cerrar la laptop. En el medio, todo es status, add, commit y diff en bucle.

Hacés git pull para traer lo del equipo, abrís tu rama con switch -c, metés mano en el código, corrés status y diff como quien se mira al espejo antes de salir, agregás con add lo que ya está terminado, confirmás con commit en pasos chicos y honestos, corregís un mensaje con amend si hace falta, chusmeás el log --oneline con cierto orgullo por la prolijidad, y al final del día volvés a main, mergeás tu rama y hacés push. Esto se conecta con lo que analizamos en qué opciones existen en seguridad y privacidad frente a GitHub.

Nada heroico. Y ese es justo el punto.

Tabla resumen: los 20 comandos git básicos y cuándo usarlos

Comando	Qué hace	Cuándo usarlo
git status	Muestra qué cambió y en qué rama estás	Cada vez que te sentás a trabajar
git add .	Pasa cambios a staging	Después de revisar status
git commit -m	Guarda una foto con mensaje	Al cerrar una unidad de trabajo chica
git diff –staged	Muestra qué va al próximo commit	Antes de confirmar, no después
git log –oneline	Historia completa en una línea por commit	Para ver el panorama rápido
git switch -c	Crea y te mueve a una rama nueva	Al arrancar una tarea nueva
git merge	Integra una rama a main	Cuando el trabajo ya está probado
git fetch	Descarga sin fusionar	Cuando querés inspeccionar primero
git pull	Descarga y fusiona	Al arrancar el día, con el equipo
git push origin main	Sube commits al remoto	Al cerrar el día de trabajo

Errores comunes al usar estos comandos git básicos

• Usar git add . sin revisar status antes: así se cuelan archivos que no querías, como un .env con credenciales, si no están bien listados en el .gitignore.
• Escribir mensajes de commit vagos: “fix” o “cambios” no le sirven a nadie, ni siquiera a vos mismo revisando el log dentro de tres meses.
• Usar commit –amend después de hacer push: reescribís historia que tus compañeros ya bajaron, y eso les rompe el trabajo cuando intenten sincronizar.
• Confundir pull con fetch: pull fusiona de inmediato; si tenías cambios locales sin terminar, podés terminar con un conflicto que no esperabas.

Preguntas Frecuentes

¿Cuál es el comando git más usado?

Para la mayoría de los desarrolladores es git status, seguido de add, commit, push y pull. Status es el paso seguro cuando volvés a un proyecto y no estás seguro de en qué estado quedaron los archivos.

¿Cuál es la diferencia entre git fetch y git pull?

Fetch descarga commits nuevos pero no toca tu rama actual. Pull descarga y fusiona de inmediato. Usá fetch primero cuando quieras mirar antes de mezclar los cambios.

¿Cómo deshago el último commit sin perder los cambios?

Con git reset --soft HEAD~1. El commit desaparece de la historia, pero todos sus cambios quedan en staging, listos para confirmarlos de nuevo de mejor forma.

¿Necesito GitHub para usar Git?

No. Git funciona completo en tu propia computadora, sin cuenta y sin internet. GitHub es solo un lugar popular para guardar una copia remota y trabajar con otras personas.

¿Qué hace git add . exactamente?

Mueve todos los archivos modificados de la carpeta actual a la zona de staging, en un solo paso. Es cómodo, pero conviene correr git status antes para no subir algo sin querer.

Conclusión

No hace falta memorizar cien flags raros para usar Git bien. Con los veinte comandos de este cheat sheet, repetidos en el orden de un día normal de trabajo (pull, status, add, commit, diff, branch, merge, push), cubrís casi todo lo que te va a pedir cualquier proyecto real. Guardá esta lista cerca del teclado durante dos semanas y el patrón se te va a quedar solo.

Si gestionás tus propios proyectos y necesitás dónde alojarlos más allá del repositorio en sí, para sitios y aplicaciones en producción en Argentina conviene mirar opciones de hosting locales como donweb.com.

Fuentes

• Git oficial (git-scm.com) – documentación oficial del proyecto
• Git Commands Cheat Sheet for Beginners – CodingCush en dev.to