Comandos habituales de Git

Git es un sistema de control de versiones que registra todos los cambios de tu código, permite el trabajo en paralelo en ramas independientes y facilita unir esas ramas para obtener la versión final o de producción. Aquí tienes, ordenado por flujo de trabajo, el conjunto de comandos de Git que uso «sí o sí» en cada proyecto, con la estructura y el detalles para que sean útiles de verdad.

01 Cómo funciona Git: tres zonas

Para entender los comandos conviene tener clara la idea de las tres zonas de Git:

• Working tree (directorio de trabajo): los ficheros tal como los tienes en tu disco.
• Index / Staging (área de preparación): lo que has marcado con git add y entrará en el próximo commit.
• HEAD / repositorio: el último commit confirmado de la rama actual.

El ciclo básico es: editas → git add → git commit → git push. Cuando algo no se comporta como esperas, casi siempre es porque el fichero está en una zona distinta a la que crees.

02 Configuración inicial

Antes de empezar, deja configurada tu identidad (queda grabada en cada commit) y algunas preferencias:

git config --global user.name "Tu Nombre"
git config --global user.email "tu@email.com"
git config --global core.autocrlf true        # saltos de línea estilo Linux
git config core.ignorecase false              # Git distingue mayúsculas/minúsculas
git config --global init.defaultBranch main   # rama por defecto al hacer init
git config --global alias.st "status -sb"     # alias útiles
git config --list                             # ver toda la configuración

03 Crear o clonar un proyecto

Proyecto nuevo desde cero:

git init                 # crea el repositorio en la carpeta actual
git checkout -b dev      # crea y salta a la rama dev (o: git switch -c dev)
git remote add origin git@github.com:usuario/proyecto.git
git remote -v            # ver los remotos configurados

Descargar un proyecto existente (clonar) y saltar directamente a una rama:

git clone -b dev git@github.com:usuario/proyecto.git

04 Ciclo diario: añadir, confirmar y subir

git status            # qué ficheros han cambiado y en qué zona están
git add .              # añadir TODO lo creado/modificado al staging
git add "fichero.php"  # añadir solo un fichero
git rm "fichero.php"   # eliminar un fichero (del disco y del índice)
git commit -m "Mensaje"  # confirmar los cambios del staging
git push               # subir los commits a la rama remota
git pull               # traer y fusionar los cambios del remoto
git fetch --all        # traer los cambios SIN fusionarlos

Regla de oro: commit pequeño y con mensaje descriptivo. Un commit que mezcla «arreglo CSS + nueva feature + refactor» es imposible de revertir o revisar.

Primera subida a un repositorio nuevo (para que la rama local quede vinculada a la remota):

git push -u origin dev

El -u guarda el upstream: a partir de ahí, un simple git push o git pull sabe a qué rama remota ir.

05 Ramas: trabajar en paralelo

git checkout -b "nombre_nueva_rama"   # crea y cambia a una nueva rama
git switch -c "nombre_nueva_rama"      # versión moderna de lo anterior
git branch -a                          # lista ramas locales y remotas
git branch -m vieja nueva              # renombrar rama local

# renombrar una rama ya subida al remoto:
git push origin :nombre_vieja          # borra la rama vieja del remoto
git push origin nombre_nueva

Para integrar el trabajo de una rama en otra tienes dos caminos:

• Merge (git checkout dev && git merge feature): crea un commit de fusión; conserva el historial tal cual fue.
• Rebase (git checkout feature && git rebase dev): reescribe los commits de la rama sobre la base actual, dejando un historial más lineal. Nunca hagas rebase de una rama compartida (que ya hayas subido con otros trabajando) porque reescribe historia.

06 Deshacer, revisar y recuperar

Antes de deshacer nada, mira dónde estás: un reset afecta al índice y, con --hard, también al directorio de trabajo.

git log --oneline --graph --all   # historial visual en una línea
git log -p                        # historial con los cambios (diff)
git diff                          # cambios sin preparar (working vs index)
git diff --staged                 # cambios preparados (index vs HEAD)
git stash                         # guarda temporalmente lo sin confirmar
git stash pop                     # recupera lo guardado
git reset HEAD fichero            # saca un fichero del staging (sin borrar nada)
git reset --soft HEAD~1           # deshace el último commit, deja cambios en staging
git reset --hard HEAD~1           # deshace el último commit y sus cambios (¡peligro!)
git revert HEAD                   # nuevo commit que deshace el anterior (seguro, no reescribe)
git commit --amend -m "nuevo msg" # corrige el mensaje/contenido del último commit
git tag v1.0.0                    # etiqueta de versión

07 Ignorar ficheros y limpiar la caché

Con un fichero .gitignore en la raíz evitas subir cosas que no deben versionarse (dependencias, ficheros generados, secretos):

# .gitignore
node_modules/
vendor/
.env
*.log
.DS_Store

Si un fichero ya estaba versionado y quieres que git lo deje de seguir sin borrarlo del disco (típico con .env o carpetas de caché):

git rm -r --cached [ruta_del_fichero_o_carpeta]
git commit -m "Deja de versionar [ruta]"

08 Errores y situaciones habituales

• Conflicto de merge: Git marca los ficheros con <<<<<<< HEAD / >>>>>>> rama. Edita, decide qué dejar, git add y git commit.
• Subir credenciales: nunca hagas git add . con un .env o claves en el repo; añádelos a .gitignore antes.
• «Refusing to update checked out branch»: estás intentando hacer push a la rama sobre la que está trabajando otra persona/entorno; usa una rama nueva o un bare / receive.denyCurrentBranch.
• Saltos de línea: si el repo se «ensucia» al abrirlo en Windows, normaliza con core.autocrlf (true en Windows, input si trabajas desde Linux).
• Rama con cambios sin confirmar: antes de cambiar de rama, confirma (o haz git stash), o Git te lo pedirá.

09 Conclusión

Con estos comandos cubres el 80% del trabajo diario: configurar, clonar/crear, confirmar y subir, trabajar en ramas, y deshacer con cabeza. La clave no es memorizar todos los comandos, sino entender las tres zonas y a qué remoto y rama está apuntando tu repositorio en cada momento.

10 Notas y referencias