Cheatsheet Git

Git es un sistema de control de versiones distribuido, creado por Linus Torvalds en 2005 (el mismo creador de Linux) para reemplazar a BitKeeper en el desarrollo del kernel.

Características principales:

• Distribuido: cada usuario tiene el repositorio completo localmente, con todo el historial.
• Rápido: operaciones como commit, branch y merge se hacen localmente, sin red.
• Seguro: cada cambio está protegido por un hash SHA-1, lo que hace el historial prácticamente inviolable.

git config --list
git config --global --list
git config user.name
git config --show-origin --list

El --list muestra todos los ajustes activos (system, global y local). Para ver solo un valor, pasa la clave, por ejemplo user.name. El --show-origin indica de qué archivo (.gitconfig) viene cada ajuste — útil para resolver conflictos de configuración.

git init
git init mi-proyecto
git init --bare repositorio.git

git init crea la carpeta oculta .git con toda la estructura interna del repositorio. Con un nombre de carpeta, crea también el directorio. La flag --bare crea un repositorio sin working directory, usado en servidores.

Atención: si ya existe una carpeta .git, no ejecutes esto de nuevo — podrías corromper el historial.

Git lee la configuración en tres niveles, del más general al más específico:

• --system: todo el ordenador (archivo /etc/gitconfig).
• --global: tu usuario (archivo ~/.gitconfig).
• --local: solo el repositorio actual (archivo .git/config) — es el nivel por defecto.

El nivel más específico siempre gana: un ajuste --local se sobrepone a --global, que se sobrepone a --system.

git clone https://github.com/usuario/repositorio.git
git clone https://github.com/usuario/repositorio.git carpeta-local
git clone --depth 1 https://github.com/usuario/repositorio.git
git clone -b develop https://github.com/usuario/repositorio.git

git clone copia todo del repositorio remoto (historial, branches, tags) a tu máquina y crea automáticamente el enlace a origin. El --depth 1 hace un clone superficial (solo el último commit, más rápido). El -b clona directamente una branch específica.

git --version
git help config
git config --help

git --version muestra la versión instalada — útil para confirmar si tienes funcionalidades recientes como git switch (Git 2.23+). El git help comando abre el manual completo de cualquier comando.

git config --global user.name "O Tu Nombre"
git config --global user.email "email@ejemplo.com"
git config --global init.defaultBranch main
git config --global core.editor "code --wait"

Define la identidad que Git registra en cada commit. La flag --global se aplica a todo el usuario; sin ella, la configuración queda solo en el repositorio actual. El init.defaultBranch define el nombre de la branch inicial y core.editor el editor usado en los mensajes.

git status
git status -s
git status --ignored

El comando más usado en Git. Muestra la branch actual, los archivos cambiados, los que están en staging (listos para el próximo commit) y los no rastreados. El -s da una versión corta y el --ignored incluye archivos ignorados por .gitignore.

git commit -am "Actualizar dependencias"

El -a añade automáticamente todos los archivos ya rastreados y modificados, saltando el git add. Atención: los archivos nuevos (no rastreados) no se incluyen — esos siguen necesitando git add.

node_modules/
.env
*.log
dist/
!dist/.gitkeep

El archivo .gitignore le dice a Git qué archivos no deben ser rastreados: dependencias (node_modules/), secretos (.env), logs y artefactos de build. El ! niega un patrón (lo vuelve a incluir). Los archivos ya versionados no se ignoran — usa git rm --cached primero.

git add fichero.php
git add .
git add -p
git add *.js

El staging es la "sala de espera" antes del commit: eliges exactamente lo que entra. El git add . añade todo; el -p (patch) permite revisar y aprobar parte por parte de cada archivo. Nunca hagas commits a ciegas: git status + git add te da control total.

git diff
git diff --staged
git diff main..feature
git diff HEAD~3

git diff muestra los cambios fuera del staging; con --staged muestra lo que ya está preparado para el próximo commit. Puedes comparar dos branches con main..feature o tu trabajo contra un commit antiguo con HEAD~3.

Cada archivo en Git vive en uno de tres estados:

• Working directory: los archivos tal como están en tu disco, con cambios sin guardar.
• Staging area: lo que preparaste con git add para el próximo commit.
• Repositorio: lo que ya se ha guardado con git commit.

El flujo normal es siempre: editar → git add → git commit.

git commit -m "Mensaje clara e útil"

Un commit es un punto guardado en la línea temporal del proyecto. Los buenos mensajes ahorran horas de debugging: describe qué se hizo y por qué, no solo "fix". Regla de oro: título corto y directo, hasta 50 caracteres.

git rm fichero.txt
git rm -r carpeta/
git rm --cached fichero.txt

git rm borra el archivo del repositorio y del disco. El --cached quita solo del repositorio, manteniendo el archivo local — la forma correcta de dejar de versionar algo que debe pasar al .gitignore.

git commit -m "Adicionar validación de email" -m "Impede registros com emails inválidos. Valida formato e dominio."

El primer -m es el título; el segundo queda como cuerpo del mensaje. Git lee la primera línea como título — debe ser corto y directo. Usa el cuerpo para explicar el contexto y el porqué del cambio.

git mv antiguo.php nuevo.php
git mv fichero.php carpeta/

git mv renombra o mueve archivos manteniendo el historial de cambios asociado. Es el equivalente a hacer mv + git add en un solo paso, y Git registra la operación como rename.

git log
git log -5
git log --stat

Muestra el historial de commits de la branch actual: IDs (SHA-1), autores, fechas y mensajes. El -5 limita a los últimos cinco y el --stat añade un resumen de los archivos cambiados en cada commit.

git log -S "nomeDaFuncao"
git log -S "nomeDaFuncao" --oneline

El -S (pickaxe) encuentra los commits que añadieron o quitaron aquel texto en el código — no solo en el mensaje. Es la herramienta correcta para descubrir en qué commit se introdujo una función o un bug.

git bisect start
git bisect bad
git bisect good v1.0
git bisect reset

git bisect hace una búsqueda binaria en el historial: marcas un commit bueno (good) y uno malo (bad), y Git va probando los del medio hasta encontrar el commit exacto que introdujo el bug. El git bisect reset te devuelve a la branch original.

git log --oneline
git log --oneline -10

Muestra cada commit en una sola línea, con el ID abreviado y el mensaje. Es la forma más rápida de tener una visión general y limpia del historial del proyecto.

git show
git show a1b2c3d
git show a1b2c3d --stat

Sin argumentos, muestra el último commit con el diff completo. Con un ID (basta el prefijo, ej.: a1b2c3d), muestra ese commit. También funciona para ver el contenido de una tag o de un archivo en otro punto del historial.

git shortlog -sn
git shortlog -sn --since="1 year ago"

git shortlog -sn agrupa los commits por autor con el conteo, ordenado del más activo al menos. Ideal para informes rápidos de actividad del equipo.

git log --oneline --graph --all
git log --graph --pretty=format:'%h %d %s (%an)' --all

Combina --oneline, --graph (dibujo ASCII de las ramificaciones) y --all (todas las branches, no solo la actual). Permite visualizar rápidamente la estructura del proyecto y cómo las branches se conectan en los merge.

git blame fichero.php
git blame -L 10,20 fichero.php
git blame -w fichero.php

git blame muestra, línea a línea, el último commit y el autor que tocó cada una. El -L 10,20 limita al intervalo de líneas y el -w ignora cambios de espacios. Útil para entender el origen de código extraño — ¡sin juicios!

git log --author="Nombre"
git log --grep="palabra"
git log --since="2 weeks ago"
git log -- app/Models/

Filtra commits por autor (--author), por texto en el mensaje (--grep), por fecha (--since/--until) o por ruta de archivo. Esencial para encontrar "quién hizo esto" o "cuándo apareció aquel bug".

git reflog
git reflog --date=iso
git checkout a1b2c3d

reflog registra todos los movimientos del HEAD — incluso commits "borrados" por un reset. Es la red de seguridad de Git: encuentra el ID del commit perdido y recupéralo con git checkout o git reset. Nada está verdaderamente perdido.

git branch feature/nombre-da-branch

Las branches son "universos paralelos" de tu código: main es la línea temporal oficial y las demás son ramificaciones donde trabajas sin estropear nada. Convenciones más usadas: feature/ (nuevas funcionalidades), bugfix/ (bugs del día a día), hotfix/ (urgencias en producción) y release/ (preparar versiones).

git checkout -b feature/login

Crea la branch feature/login y cambia enseguida a ella. Combina git branch (crear) y git checkout (cambiar) en un solo paso — la forma más rápida de empezar una funcionalidad nueva.

git branch -D nombre
git push origin --delete nombre

El -D borra la branch incluso sin merge — atención, el trabajo no integrado se pierde (aunque el reflog todavía lo guarda por un tiempo). El push origin --delete quita la branch del repositorio remoto.

git branch
git branch -v
git branch --merged

Lista las branches locales y marca con * aquella en la que estás. El -v muestra el último commit de cada una y el --merged lista las que ya están integradas en la branch actual — buenas candidatas a borrar.

git switch nombre-da-branch
git switch -c feature/login
git switch -

git switch (Git 2.23+) hace solo la parte del checkout que cambia de branch, sin los efectos secundarios peligrosos (como restaurar archivos). El -c crea y cambia, y el - vuelve a la branch anterior.

git branch -a
git branch -r

El -a muestra todas las branches (locales y remotas); el -r solo las remotas (ej.: origin/main). Las remotas son "fotografías" del servidor, actualizadas con git fetch.

git branch -m nuevo-nombre
git branch -m nombre-antiguo nuevo-nombre

El -m renombra la branch actual (o la indicada). Si la branch ya estaba en el remoto, tendrás que borrar la remota antigua con git push origin --delete y hacer push de la nueva con -u.

git checkout nombre-da-branch

Actualiza los archivos del working directory para que reflejen la branch elegida y mueve el puntero HEAD hacia ella. Git bloquea el cambio si hay cambios sin guardar que entren en conflicto — usa git stash en esos casos.

git branch -d nombre

git branch -d borra la branch solo si ya ha sido integrada (merged) en otra. Es la forma segura de limpiar branches que ya no se necesitan, sin riesgo de perder trabajo.

git checkout main
git merge bugfix/nombre-da-branch

git merge crea un merge commit que une el trabajo de la branch a la actual, preservando el historial tal como ocurrió. Ideal para equipos, porque registra cuándo y cómo se integró cada funcionalidad.

git merge --abort
git rebase --abort

Si un merge o rebase salió mal (conflictos imposibles, por ejemplo), el --abort cancela la operación y devuelve todo al estado anterior, sin daños. Es el "botón de pánico" oficial.

git merge --no-ff feature/login

Por defecto, si la branch no divergió, Git solo avanza el puntero (fast-forward) y el merge queda invisible en el historial. El --no-ff fuerza la creación del merge commit, manteniendo visible que aquella funcionalidad existió como branch.

<<<<<<< HEAD
o tu código
=======
código da outra branch
>>>>>>> nombre-da-branch

Cuando Git no consigue unir dos versiones de la misma línea, marca el archivo con <<<<<<< HEAD, ======= y >>>>>>>. Pasos: abre el archivo, elige qué mantener (puedes mezclar o reescribir), quita las marcas, guarda y finaliza con git add . y git commit.

git checkout main
git merge --squash feature/login
git commit -m "Adicionar login"

El --squash une todos los commits de la branch en un único conjunto de cambios, que commiteas manualmente. Ideal para transformar branches con decenas de commits "wip" en un único commit limpio en main.

git cherry-pick a1b2c3d
git cherry-pick a1b2c3d b2c3d4e
git cherry-pick --no-commit a1b2c3d

Aplica un commit específico (por ID) a la branch actual, sin hacer merge de la branch entera. Útil para llevar una corrección urgente a la release sin arrastrar el resto de la feature. El --no-commit aplica los cambios sin commitear.

git checkout feature
git rebase main

"Teletransporta" tus commits como si se hubieran hecho después de los últimos de main, quedando el historial lineal y limpio. Peligroso en branches compartidas en el remoto: reescribir el historial ajeno causa conflictos y pérdida de trabajo.

Merge: preserva el historial real, crea merge commits, seguro en branches compartidas. Úsalo cuando trabajas en equipo en el remoto.

Rebase: reescribe el historial para que quede lineal, más limpio de leer. Úsalo solo en branches locales y personales, antes de hacer push.

Regla de oro: nunca hagas rebase en branches públicas que otros también usan.

git remote add origin https://github.com/usuario/repo.git

Añade el repositorio remoto con el nombre origin (convención para el remoto principal). A partir de aquí puedes usar git push y git fetch para sincronizar con GitHub, GitLab o Bitbucket.

git pull
git pull origin main

Trae los cambios del remoto y los aplica automáticamente a tu branch actual. Es el equivalente a git fetch + git merge. Si hay divergencias, puede generar conflictos o un merge commit.

git push -u origin nombre-da-branch

Envía la branch y la conecta a la remota (define el upstream). A partir de ahí, git push y git pull funcionan sin argumentos — Git ya sabe de dónde viene y a dónde va el código.

git remote
git remote -v
git remote show origin

Lista los remotos configurados. El -v muestra las URLs de fetch y push (permite confirmar si usas HTTPS o SSH). El git remote show origin da el detalle completo: branches rastreadas y estado de sincronización.

git fetch: descarga las novedades pero no toca tu código — seguro para echar un vistazo. git pull: descarga e integra enseguida en tu branch. En la duda, usa fetch primero, mira lo que cambió con git log origin/main, y solo después decide entre merge o rebase.

git push --force-with-lease
git push --force

Después de un rebase, el historial diverge del remoto y el push normal es rechazado. El --force sobrescribe el remoto ciega y peligrosamente; el --force-with-lease solo avanza si nadie ha enviado commits nuevos — usa siempre este.

git remote rename origin upstream
git remote remove upstream

El rename cambia el nombre de un remoto (y actualiza todas las referencias). El remove borra el enlace — tus commits locales no se ven afectados, solo dejas de poder hacer push/pull hacia esa dirección.

git pull --rebase
git config --global pull.rebase true

Trae los cambios del remoto y reaplica tus commits por encima, sin crear merge commits. Mantiene el historial limpio y lineal. Puedes hacer que este comportamiento sea el predeterminado con la configuración pull.rebase true.

git fetch
git fetch origin
git fetch --all --prune

Descarga las novedades del remoto (nuevos commits, branches) sin alterar tu trabajo local — puedes inspeccionar antes de decidir. El --prune borra las referencias locales a branches remotas que ya se han borrado en el servidor.

git push origin nombre-da-branch
git push

Envía los commits de tu branch local al remoto origin. Si la branch no existe en el remoto, se crea. Después de definir el upstream (ver la siguiente card), basta git push.

git stash
git stash push

Guarda los cambios no commiteados y devuelve el working directory al estado limpio del último commit. Perfecto cuando necesitas cambiar de branch "ahora mismo" sin perder el trabajo en curso.

git stash apply
git stash apply stash@{2}

git stash apply reaplica los cambios guardados al working directory sin quitar el stash de la lista — puedes aplicarlo en varias branches o mantener la copia de seguridad.

git stash push -m "WIP: formulario de login"

La flag -m da un mensaje al stash — esencial para identificarlo en la lista cuando tienes varios guardados. Sin ella, Git usa el mensaje genérico WIP on branch..., difícil de distinguir.

git stash pop

Aplica el stash más reciente y lo quita de la lista, en un solo paso. Es el flujo normal: guardaste con git stash, vuelves al trabajo con git stash pop.

git stash -u
git stash --include-untracked

Por defecto, el stash ignora archivos nuevos (no rastreados). El -u los incluye — útil cuando creaste archivos que aún no habían recibido git add.

git stash drop stash@{0}

Borra un stash de la lista sin aplicarlo. Usa el identificador que ves en git stash list — por ejemplo stash@{1} para el segundo más reciente.

git stash list
git stash show stash@{1}
git stash show -p stash@{1}

Lista todos los stashes con identificadores stash@{0}, stash@{1}, etc. (el {0} es el más reciente). El show resume los cambios y el -p muestra el diff completo — para que veas lo que guardaste antes de aplicar.

git stash clear

Borra todos los stashes de una vez. Atención: no hay confirmación ni un reflog que los devuelva fácilmente — confirma con git stash list antes.

git commit --amend -m "Nueva mensaje"
git add fichero-esquecido.php
git commit --amend --no-edit

Reescribe el último commit: cambia el mensaje o añade archivos olvidados (con --no-edit mantiene el mensaje). Solo en commits locales — hacer amend a un commit ya enviado reescribe el historial y causa confusión en el remoto.

git restore fichero.php
git restore .

Revierte el archivo al estado del último commit, descartando los cambios no guardados. Es el sustituto moderno del antiguo git checkout -- fichero. Atención: los cambios descartados no son recuperables.

git reset HEAD~1
git reset HEAD~3

Deshace el último commit pero mantiene los cambios en el working directory (modo mixed, el predeterminado). El numero después del ~ indica cuántos commits retroceder: HEAD~3 quita los tres últimos.

git revert a1b2c3d
git revert HEAD

Crea un nuevo commit que anula los cambios del commit indicado, sin tocar el historial. Es la única forma segura de deshacer en branches compartidas — al contrario que el reset, que reescribe el pasado.

git reset --soft HEAD~1
git reset --mixed HEAD~1
git reset --hard HEAD~1

--soft: quita el commit, mantiene todo en staging. --mixed (predeterminado): quita el commit y el staging, mantiene los archivos. --hard: borra todo — commit, staging y cambios en el disco. El --hard es destructivo: úsalo solo con certezas.

git clean -n
git clean -f
git clean -fd
git clean -fdx

Borra archivos no rastreados del working directory. El -n es un ensayo (muestra lo que se borraría, sin borrar); el -f fuerza, el -d incluye carpetas y el -x también los ignorados por el .gitignore. Haz siempre -n primero.

git restore --staged fichero.php
git restore --staged .

Deshace el git add: el archivo sale del staging area pero los cambios siguen en el disco. Permite corregir lo que entrará en el próximo commit sin perder trabajo.

git reset: mueve el puntero HEAD hacia atrás — reescribe el historial, solo para commits locales. git revert: crea un commit que anula otro — seguro en el remoto. git restore: deshace cambios en archivos (en el disco o en el staging), sin tocar commits. Regla simple: local → reset; compartido → revert; archivos → restore.

git rebase -i HEAD~3
git rebase --continue

Abre un editor con los últimos 3 commits para que los reescribas: cambiar el orden, unir (squash), renombrar (reword) o borrar (drop). Después de guardar, continúa con git rebase --continue. Ideal para limpiar commits "wip" antes de un push.

# .git/hooks/pre-commit
#!/bin/sh
php artisan test

Los hooks son scripts ejecutados automáticamente en puntos clave: pre-commit (antes de cada commit — ideal para correr tests o linters), commit-msg (validar el mensaje), pre-push, etc. Viven en la carpeta .git/hooks/ y no se versionan por defecto.

git gc
git prune
git count-objects -v

El git gc (garbage collection) comprime el historial y elimina objetos inaccesibles, manteniendo la carpeta .git pequeña y rápida. Git ya lo ejecuta automáticamente de vez en cuando; fuérzalo en repositorios muy antiguos o tras grandes limpiezas.

En el editor del rebase -i, cada línea empieza por un comando:

• pick: mantiene el commit como está.
• reword: lo mantiene pero edita el mensaje.
• squash: lo une al commit anterior (manteniendo los mensajes para editar).
• fixup: lo une al anterior, descartando el mensaje.
• drop: borra el commit.
• edit: se detiene en ese commit para que lo alteres (con --amend).

git archive -o release-v1.0.zip v1.0.0
git archive --format=tar.gz --prefix=app/ HEAD > app.tar.gz

Exporta el estado del proyecto en un punto dado (tag, branch o commit) a un zip o tar — sin el historial .git. Ideal para entregar releases o hacer backups del código.

git tag v1.0.0
git tag -a v1.0.0 -m "Versión 1.0.0"
git tag -l "v1.*"
git push origin v1.0.0
git push origin --tags

Las tags marcan puntos fijos del historial, normalmente versiones (v1.0.0). Las anotadas (-a) guardan autor, fecha y mensaje. Las tags no van al remoto automáticamente — usa git push origin --tags.

git config --global alias.st status
git config --global alias.co checkout
git config --global alias.lg "log --oneline --graph --all"

Los aliases crean atajos para los comandos que más usas. Después de alias.st status, basta escribir git st. El clásico git lg te da el historial visual completo con tres teclas.

git worktree add ../proyecto-hotfix hotfix/urgente
git worktree list
git worktree remove ../proyecto-hotfix

El worktree crea una segunda carpeta de trabajo del mismo repositorio, en otra branch — sin clones duplicados. Perfecto para corregir un bug urgente sin guardar lo que tienes entre manos con stash.

git submodule add https://github.com/lib/dependencia.git libs/dep
git submodule update --init --recursive
git clone --recurse-submodules URL

Los submodules embeben otro repositorio dentro del tuyo, con la versión fijada en un commit específico. Después de clonar un proyecto con submodules, el --init --recursive los descarga. Alternativas modernas: paquetes vía composer o npm.

Cuando Git abre vim (en un commit sin -m, por ejemplo), estás en modo normal — las teclas no escriben. Para editar, pulsa:

• i → insertar donde está el cursor
• a → insertar después del cursor
• o → crear una línea nueva debajo

Verás -- INSERT -- en el pie. Para volver al modo normal, pulsa Esc.

⚡ PERF – Mejoras de rendimiento. Ex.: ⚡ PERF: otimizar query da base de datos.

🔒 SECURITY – Corrección de vulnerabilidades. Ex.: 🔒 SECURITY: prevenir SQL Injection no login.

🚑 HOTFIX – Corrección urgente en producción. Ex.: 🚑 HOTFIX: resolver downtime nos pagamentos.

🗑 REMOVE – Eliminar código o archivos obsoletos. Ex.: 🗑 REMOVE: eliminar pruebas antigos.

En modo normal (después de Esc):

• :w — guardar (write)
• :q — salir (quit)
• :wq — guardar y salir
• :q! — salir sin guardar
• :x — guardar y salir, pero solo si hubo cambios

Si te quedaste atrapado en el editor durante un commit: Esc, luego :wq y Enter.

Un buen mensaje de git commit tiene tres partes:

• Título (hasta 50 caracteres): imperativo y directo — "Adicionar validación de email", no "adicionei".
• Línea en blanco para separar.
• Cuerpo (opcional): explica el porqué y el contexto, no el cómo (el código muestra eso).

Si el título necesita una "y", probablemente son dos commits.

📦 NEW – Añadir nueva funcionalidad o módulo. Ex.: 📦 NEW: crear módulo de autenticación com Google.

➕ ADD – Añadir código simple a algo ya existente. Ex.: ➕ ADD: agregar campo "telefono" no registro.

🐛 FIX – Corregir un error o comportamiento inesperado. Ex.: 🐛 FIX: corrigir fallo na validación do email.

👌 IMPROVE – Mejorar código existente (rendimiento, legibilidad). Ex.: 👌 IMPROVE: otimizar o carregamento do dashboard.

🚀 RELEASE – Publicar una nueva versión. Ex.: 🚀 RELEASE: versión 1.2.0 lanzada.

git status
git add .
git commit -m "📦 NEW: agregar paginación"
git pull --rebase
git push

El ciclo seguro del día a día: verifica el estado con git status, prepara con git add, guarda con git commit, sincroniza con git pull --rebase (resuelve conflictos localmente) y solo entonces envía con git push.

📝 DOCS – Actualizaciones de documentación. Ex.: 📝 DOCS: actualizar README com instrucciones de instalación.

🖌 STYLE – Cambios de estilo/formato (sin afectar la lógica). Ex.: 🖌 STYLE: ajustar colores e posición dos botones.

🐳 DOCKER – Cambios en configuraciones o imágenes Docker. Ex.: 🐳 DOCKER: actualizar imagen base do container.

♻ REFACTOR – Refactorización sin cambiar el comportamiento. Ex.: ♻ REFACTOR: dividir funcion grande em métodos menores.

✅ TEST – Añadir o mejorar tests automatizados. Ex.: ✅ TEST: pruebas unitarios para autenticación.

Los nombres consistentes mantienen el repositorio predecible:

• feature/nombre — funcionalidad nueva (nace de main/develop).
• bugfix/nombre — bug del día a día, no crítico.
• hotfix/nombre — urgencia en producción.
• release/1.2.0 — preparación de versión (changelog, tests finales).

Usa minúsculas y guiones (feature/login-social) y sé específico: fix-bug no le dice nada a nadie.