Git · 03

Uso diario

Los comandos que vas a usar casi todos los días, cada uno con qué hace, cuándo usarlo y qué esperar. Todos se ejecutan dentro de la carpeta del repositorio.

Términos de esta página

Las ideas base (commit, área de preparación, HEAD) están en Conceptos.

Diff
La diferencia entre dos versiones de un archivo: qué líneas se agregaron (+) y cuáles se quitaron (-).
Log
El historial de commits.
Flag (opción)
Lo que va después del comando con uno o dos guiones y cambia su comportamiento, por ejemplo --oneline o -m.
Stash
Un cajón donde guardar cambios sin commitear para dejar la carpeta limpia un rato y recuperarlos después.
Tag
Una etiqueta con nombre fijo para un commit importante, típicamente una versión: v1.0.0.
Rastreado (tracked)
Un archivo que Git ya conoce porque estuvo en algún commit. Los nuevos no lo están hasta el primer git add.
Paginador
Cuando la salida es larga (por ejemplo en git log), Git la muestra por páginas: Espacio avanza y q sale.
1

Ver el estado

Correlo cada vez que dudes. No cambia nada.

git status

git status
Dice la rama actual, si estás adelante o atrás del remoto, y qué archivos están preparados, modificados o sin seguimiento.
On branch main
Your branch is up to date with 'origin/main'.

Changes to be committed:
        modified:   README.md

Changes not staged for commit:
        modified:   app.js

Untracked files:
        notas.txt

Cómo leer la salida

  • Changes to be committed: preparado con git add; entra en el próximo commit.
  • Changes not staged for commit: modificado pero no preparado; si hacés commit ahora, no entra.
  • Untracked files: archivos nuevos que Git todavía no sigue.
  • up to date with 'origin/main': tu rama tiene los mismos commits que la de GitHub (según lo último que Git sabe).
git status -s
Versión corta: M modificado, A agregado, ?? sin seguimiento. La columna de la izquierda es lo preparado y la de la derecha lo no preparado.
2

Preparar cambios (git add)

Elegir qué va a entrar en el próximo commit.

git add app.js
Prepara solo ese archivo para el próximo commit; el resto de los cambios queda afuera. Podés nombrar varios separados por espacio (git add app.js package.json).
git add .
Prepara todo lo que cambió en la carpeta actual y sus subcarpetas (respetando el .gitignore). Mirá git status antes para no incluir algo de más.
git add src/
Prepara todo lo que cambió dentro de la carpeta src/ y sus subcarpetas, sin tocar lo que cambió fuera de ella.
git add -p
Modo interactivo: te muestra cada bloque de cambios y preguntás uno por uno (y = sí, n = no, q = salir). Sirve para dividir un archivo con dos cambios distintos en dos commits.
git restore --staged app.js
Lo contrario de add: saca el archivo del área de preparación. No pierde tus cambios; solo dejan de estar preparados.
3

Guardar un commit

Formas de commitear

git commit -m "Agrega la ruta /health"
Guarda en el historial todo lo que está preparado (lo que agregaste con git add), con ese mensaje. Lo no preparado queda sin guardar en la carpeta. Escribí el mensaje en presente y diciendo qué cambia, para que se entienda al leer el historial.
git commit
Sin -m, Git abre el editor configurado para que escribas un mensaje largo. Primera línea = título; línea vacía; después el detalle. Guardá y cerrá el editor para terminar.
git commit -am "Corrige el puerto"
-a prepara automáticamente los archivos ya rastreados que cambiaron y commitea en un paso. Los archivos nuevos no entran: esos necesitan git add.
git commit --amend -m "Mensaje corregido"
Reemplaza el último commit (para corregir el mensaje o sumar un archivo olvidado). Usalo solo si todavía no hiciste push de ese commit.

Cómo escribir buenos mensajes

  • En imperativo y concreto: “Agrega validación del email”, no “cambios” ni “arreglos varios”.
  • Primera línea corta (hasta ~70 caracteres): es lo que se ve en git log --oneline y en GitHub.
  • Si el porqué no es obvio, explicalo en el cuerpo del mensaje.
  • Un commit = una idea. Si en el mensaje necesitás “y además…”, probablemente son dos commits.
Agrega healthcheck a la API

Kubernetes necesita una ruta que responda 200
para saber si el Pod está listo para recibir tráfico.
4

Ver el historial (git log)

Si la salida es larga, se abre un paginador: Espacio avanza, q sale.

Variantes útiles

git log --oneline
Muestra el historial con un commit por línea: el hash corto (el identificador del commit) y la primera línea del mensaje. El más nuevo arriba.
3ddb522 (HEAD -> main, origin/main) Desactiva ligaduras en los chips
71fc95b Update README.md
279f465 first commit

HEAD -> main: estás en main. origin/main: hasta dónde llega la rama en GitHub (según el último fetch/pull).

git log --oneline --graph --all
Dibuja las ramas con líneas: ideal para entender cómo se separan y se unen.
git log -5
Muestra solo los últimos 5 commits (cambiá el número a gusto), con el hash completo, autor, fecha y mensaje entero. Si la lista es larga, Git la muestra por páginas: Espacio avanza y q sale.

Buscar en el historial

git log --oneline -- app.js
Solo los commits que tocaron ese archivo. El -- separa opciones de nombres de archivo.
git log --stat
Además de cada commit, lista qué archivos tocó y cuántas líneas agregó (+) o quitó (-) en cada uno. Útil para encontrar cuándo se cambió algo.
git log --author="<nombre>" --since="2 weeks ago"
Filtra el historial: solo commits de esa persona (alcanza con parte del nombre o el email) en las últimas dos semanas. Las fechas aceptan formas como "2026-01-31" o "3 days ago".
git log --grep="puerto"
Muestra solo los commits cuyo mensaje contiene esa palabra. Por eso conviene escribir mensajes descriptivos. Agregá -i para no distinguir mayúsculas.
git show 3ddb522
Muestra todo sobre un commit: autor, fecha, mensaje y el diff (las líneas agregadas en verde con + y las quitadas en rojo con -). Alcanza con los primeros 7 caracteres del hash. q para salir.
5

Ver diferencias (git diff)

Qué líneas cambiaron exactamente.

Qué compara cada variante

git diff
Cambios no preparados: carpeta de trabajo contra el área de preparación.
git diff --staged
Cambios preparados: lo que va a entrar en el próximo commit. Ideal para revisar antes de commitear.
git diff HEAD
Todo lo que cambió desde el último commit, esté preparado o no. HEAD significa “el commit en el que estás parado”.
git diff main..nueva-ruta
Muestra qué cambia en nueva-ruta respecto de main: lo que se agregaría al unirlas. Sirve para revisar una rama antes de hacer merge o abrir un pull request.
git diff --stat
En vez de las líneas, un resumen: qué archivos cambiaron y cuántas líneas en cada uno. Se combina con las otras formas (git diff --staged --stat).

Cómo leer un diff

diff --git a/app.js b/app.js
@@ -3,7 +3,7 @@ import mongoose from "mongoose";
-const PORT = 3000;
+const PORT = process.env.PORT ?? 3000;
  • a/ es la versión vieja y b/ la nueva.
  • @@ -3,7 +3,7 @@: el bloque empieza en la línea 3 (en las dos versiones) y abarca 7 líneas.
  • Línea con -: se quitó. Con +: se agregó. Una línea modificada aparece como un - seguido de un +.
✓

En VS Code, el panel Control de código fuente muestra los mismos diffs lado a lado, con colores.

6

Mover, renombrar y borrar archivos

git mv viejo.js nuevo.js
Renombra o mueve y deja el cambio preparado. (Si lo renombrás desde el editor, Git lo detecta igual como renombre al hacer git add.)
git rm archivo.txt
Borra el archivo del disco y prepara el borrado para el próximo commit.
git rm --cached .env
Deja de rastrear el archivo sin borrarlo de tu disco. Se usa cuando subiste algo que debía estar en el .gitignore: después agregalo al .gitignore y commiteá.
7

Guardar cambios sin commitear (git stash)

Situación típica: estás a mitad de algo, no querés commitear todavía, y necesitás cambiar de rama o hacer git pull. git stash guarda tus cambios en un “cajón”, deja la carpeta como en el último commit, y después los devolvés.

Guardar y recuperar

git stash push -m "mitad del formulario"
Guarda los cambios de archivos rastreados con un nombre. Con -u incluye también los archivos nuevos.
git stash list
Lista lo que guardaste con stash, como un cajón: stash@{0} es lo último que guardaste, stash@{1} lo anterior, y así. Al lado aparece la rama donde estabas y el mensaje.
git stash pop
Devuelve a tu carpeta los cambios del último stash y lo saca del cajón. Si esos cambios chocan con lo que tenés ahora, aparece un conflicto (se resuelve igual que en un merge) y el stash queda guardado.

Más opciones

git stash apply stash@{1}
Devuelve uno puntual pero lo deja en el cajón (sirve para aplicarlo en varias ramas).
git stash drop stash@{1}
Borra un stash puntual sin aplicarlo: esos cambios se pierden. git stash clear vacía el cajón entero.
!

El stash es local y temporal: no se sube a GitHub. Para algo que dure, mejor un commit en una rama.

8

Marcar versiones (git tag)

Un tag es un nombre fijo para un commit, normalmente una versión publicada. A diferencia de una rama, no avanza: v1.0.0 apunta siempre al mismo commit. Es útil para saber exactamente qué código corresponde a una versión (por ejemplo, la imagen Docker chanchito:1.0.0).

git tag -a v1.0.0 -m "Primera versión estable"
Crea un tag “anotado” (con autor, fecha y mensaje) en el commit actual. Es el tipo recomendado.
git tag
Lista todos los tags del repositorio, en orden alfabético. git tag -l "v1.*" filtra por patrón.
git show v1.0.0
Muestra los datos del tag (quién lo creó, cuándo y su mensaje) y el commit al que apunta, con sus cambios. Los tags no se suben solos: git push origin v1.0.0 (o --tags para todos).
git push origin v1.0.0
Los tags no se suben con git push normal: hay que subirlos explícitamente (o todos con git push --tags).
git switch --detach v1.0.0
Ver el proyecto tal como estaba en esa versión (sin rama: modo “detached HEAD”, ver Problemas). Para volver: git switch main.

No hay comandos que coincidan con la búsqueda.