Git desde cero: los comandos del día a día (y cómo salir de los errores que más duelen)

Git tiene más de un centenar de subcomandos, pero con una docena bien aprendida cubrís casi toda tu jornada. Lo demás lo buscás cuando lo necesites.

El flujo mental antes de los comandos

Git no es una herramienta de “guardar archivos”: es un grafo de commits. Cada commit es un snapshot completo del repo, con un padre. Las ramas son punteros a commits. Los merges y rebases son formas de unir dos historias distintas.

Cuando entiendas eso, los comandos dejan de ser magia y pasan a ser operaciones sobre el grafo.

Los comandos que sí importan

git init y git clone

git init                    # arrancar un repo nuevo
git clone <url>             # bajar un repo existente
git clone <url> <carpeta>   # bajarlo con otro nombre

Los tres estados de un archivo

Un archivo en Git está en uno de tres estados: working directory, staging area o repository. El flujo es siempre:

git add archivo.ts          # working → staging
git commit -m "mensaje"     # staging → repository

Inspeccionar antes de cualquier cosa peligrosa

git status                  # qué cambió y dónde está
git diff                    # cambios sin stagear
git diff --staged           # cambios en staging
git log --oneline           # historial compacto

git status antes de git commit y antes de git checkout. Sin excepciones.

Ramas: el 80% de tu trabajo

git branch                  # listar ramas
git branch nombre           # crear rama
git switch nombre           # cambiarte (más moderno que checkout)
git switch -c nombre        # crear y cambiarte en un solo paso

Sincronizar con el remoto

git push                    # subir tu rama
git pull                    # bajar y mergear
git fetch                   # bajar sin mergear (más seguro)

Preferí git fetch + revisión + merge/rebase, en vez de git pull a ciegas.

Merge vs rebase

git merge feature           # une feature a tu rama, preservando historia
git rebase main             # reescribe tu historia encima de main

Regla práctica: rebase en tu rama local antes de abrir PR. merge cuando integrás PRs ya revisados. Mezclar mal estos dos es la causa del 90% de los historiales ilegibles.

El salvavidas: git stash

git stash                   # guardar WIP sin commitear
git stash pop               # recuperar lo guardado
git stash list              # ver qué tenés stasheado

Cuando tenés que cambiar de rama urgente y no querés commitear algo a medias.

Los errores que más cuestan y cómo salir

Commiteaste algo que no querías:

git reset --soft HEAD~1     # saca el commit, mantiene los cambios staged
git reset --mixed HEAD~1    # saca el commit y el stage, mantiene working
git reset --hard HEAD~1     # borra todo. Cuidado.

Subiste algo privado por accidente:

# No sirve `git rm` (queda en el historial). Hay que purgarlo.
git filter-repo --path archivo.txt --invert-paths
git push --force

Hiciste merge y el historial quedó feo:

git reset --hard HEAD~1     # deshace el merge si todavía no lo pusheaste

Git no borra nada de inmediato. Por defecto conserva los objetos inalcanzables al menos 30 días antes del garbage collection. Si un comando te asusta, recordá: con git reflog para encontrar el hash y git reset --hard <hash> casi siempre se vuelve atrás.

La habilidad no es saber todos los comandos: es entender el grafo y saber que casi todo lo que rompiste se puede deshacer.