Git en 10 Minutos

Cada comando de Git mueve archivos entre tres sitios: tu directorio de trabajo (los archivos que editas), el staging area (un muelle de carga para la siguiente foto), y el repositorio (el álbum de fotos permanente). Y un commit es una foto completa de tu proyecto, no un diff. Entiende estos dos hechos y la mitad de la rareza de Git se evapora.

# los tres árboles, de izquierda a derecha:
#  working dir  --add-->  staging  --commit-->  repository

git init                # empezar a trackear esta carpeta
git status              # ¿dónde está todo ahora mismo?

El noventa por ciento de la vida con Git es un bucle de tres pasos. Ejecuta git status obsesivamente — antes y después de cada comando. Es gratis, es instantáneo, y te dice en qué árbol están tus cambios. Nadie senior se avergüenza de lo seguido que lo escribe.

git status                     # 1. ¿qué cambió?
git add main.py                # 2. ponerlo en el muelle de carga
git add .                      #    (o stagear todo lo de abajo)
git commit -m "Fix login bug"  # 3. tomar la foto

git log --oneline              # el álbum, una línea por foto

Una rama no es una copia de tu código. Es un post-it apuntando a un commit — 41 bytes. Cuando haces commit, el post-it donde estás parado se mueve hacia adelante. Por eso crear una rama es instantáneo, y por eso deberías crearlas sin miedo. HEAD es simplemente "el post-it donde estás parado ahora."

git switch -c try-new-parser   # escribir un post-it, pararte en él
# ...trabaja, haz commits como siempre...

git switch main                # volver — tus archivos cambian en disco
git merge try-new-parser       # traer el experimento a main
git branch -d try-new-parser   # tirar el post-it (los commits quedan)

GitHub guarda una copia completa del repositorio, apodada origin. push manda tus snapshots nuevos arriba; pull baja los snapshots de tus compañeros. Eso es todo. El famoso error de rechazo asusta a todos una vez — y su solución es un hábito: pull antes de push.

git clone https://github.com/user/repo.git   # copiar + conectar origin
git pull                       # traer lo último antes de empezar
git push                       # publicar tus commits

git push -u origin my-branch   # primer push de una rama nueva

"¿Cómo deshago ___ en Git?" es la pregunta más buscada en software. Aquí está la respuesta completa, organizada por lo que quieres deshacer. Una regla primero: si el commit ya fue pusheado, usa revert (añade un anti-commit) en vez de reset (reescribe la historia bajo los pies de tus compañeros).

# quitar un archivo del staging (conservar las ediciones)
git restore --staged secret.txt

# tirar MIS EDICIONES de un archivo — cuidado, se pierden de verdad
git restore oops.py

# rehacer el mensaje del último commit
git commit --amend -m "Mejor mensaje"

# deshacer último commit, CONSERVAR el trabajo (el deseo más común)
git reset --soft HEAD~1

# deshacer un commit ya pusheado — el undo público seguro
git revert abc1234

Un conflicto no es un error. Es Git diciendo: "dos personas editaron las mismas líneas — no voy a adivinar." Entonces escribe ambas versiones en el archivo con marcadores y espera. Tu trabajo: abre el archivo, quédate con lo que deba sobrevivir, borra los marcadores, haz commit. Esa es toda la ceremonia.

CONFLICT (content): Merge conflict in config.py

# dentro de config.py encontrarás:
<<<<<<< HEAD
timeout = 30          # tu versión
=======
timeout = 60          # la versión de ellos
>>>>>>> feature-x

# edita con la verdad (quizás timeout = 60, quizás algo nuevo),
# BORRA las tres líneas de marcadores, luego:
git add config.py
git commit

Un día harás checkout de un commit viejo para ver algo, y Git imprimirá el párrafo más aterrador del software. Traducción: estás parado directamente en un commit en vez de en un post-it. Mirar alrededor es completamente seguro. El único riesgo es hacer commits nuevos aquí — no pertenecen a ninguna rama, así que es fácil perderlos.

git switch --detach abc1234    # viajar en el tiempo para inspeccionar un snapshot viejo

You are in 'detached HEAD' state. You can look around, make
experimental changes and commit them, and you can discard any
commits you make in this state without impacting any branches...

git switch -                   # terminé de mirar — volver a donde estaba

# ¿hiciste commits aquí que quieres CONSERVAR?
git switch -c rescued-work     # pegarles un post-it — salvados

Un archivo llamado .gitignore lista lo que Git debe fingir que no existe: dependencias, output de build, archivos .env con keys dentro. Escríbelo en los primeros diez minutos de cada proyecto, porque tiene una trampa: solo afecta archivos que Git no está trackeando ya.

# .gitignore
node_modules/
.env
*.log
__pycache__/

# "¡Añadí .env al .gitignore pero Git sigue trackeándolo!"
# — fue committeado antes. Deja de trackearlo (conserva el archivo local):
git rm --cached .env
git commit -m "Stop tracking .env"

Las líneas que todo el mundo busca en Google. Organizadas por la frase que tienes en la cabeza.

# "¿en qué estado está todo?"
git status

# "guardar mi trabajo"
git add .  &&  git commit -m "message"

# "deshacer mi último commit pero conservar el trabajo"
git reset --soft HEAD~1

# "este commit pusheado fue un error"
git revert <hash>

# "tirar mis ediciones de este archivo"
git restore <file>

# "mi push fue rechazado"
git pull   # luego push de nuevo

# "estoy en un merge infernal, eyectar"
git merge --abort

# "borré algo importante"
git reflog   # encuéntralo, luego: git reset --hard HEAD@{n}

# "guardar mi desorden, necesito un escritorio limpio 5 minutos"
git stash    # después: git stash pop

Ese es el kit de supervivencia. La verdad profunda sobre Git: casi nunca pierde tu trabajo — simplemente lo archiva en algún lugar que no has aprendido a buscar todavía. Cada mensaje aterrador de esta página tiene una salida de dos líneas. Ahora las conoces todas.