Guía de referencia de comandos Git con ejemplos

Git es la herramienta de control de versiones más usada del mundo, y aunque existen clientes gráficos, la línea de comandos sigue siendo el entorno más rápido, flexible y universal para trabajar con repositorios. Conocer los comandos esenciales te permite moverte con confianza en cualquier proyecto, servidor o entorno de CI/CD.

Esta guía recoge los comandos Git más utilizados en el día a día, con ejemplos, opciones útiles y notas sobre cuándo usar cada uno. Si no estás familiarizado con términos como commit, rama, HEAD o staging area, te recomendamos empezar por la guía de términos comunes de Git.

Tabla de referencia rápida

Si ya conoces Git y solo necesitas recordar la sintaxis, aquí tienes un resumen de los comandos más frecuentes:

Comando	Descripción resumida
git clone <url>	Clonar un repositorio remoto
git init	Inicializar un repositorio nuevo
git status	Ver el estado actual del área de trabajo
git add .	Preparar todos los cambios para commit
git commit -m "msg"	Crear un commit con mensaje
git push origin main	Subir commits al remoto
git pull	Descargar y fusionar cambios del remoto
git fetch	Descargar cambios sin fusionar
git branch	Listar ramas locales
git checkout -b <rama>	Crear y cambiar a una nueva rama
git merge <rama>	Fusionar otra rama en la actual
git stash	Guardar cambios temporales sin commit
git log --oneline	Historial de commits compacto
git diff	Ver cambios pendientes
git revert <id>	Deshacer un commit preservando historial
git reset --hard HEAD	Descartar todos los cambios locales

Comandos básicos de Git

1. Inicializar un repositorio

git init

Crea un repositorio Git nuevo en el directorio actual. Genera la carpeta oculta .git/ donde Git almacena todo el historial.

• Cuándo usarlo: al empezar un proyecto nuevo desde cero, antes de conectarlo a un remoto como GitHub o GitLab.
• Para conectarlo a un remoto después: git remote add origin <url>

2. Clonar un repositorio

git clone URL-del-repositorio

Crea una copia local completa del repositorio remoto, incluyendo todo el historial y todas las ramas.

• Cuándo usarlo: al incorporarte a un proyecto existente o para trabajar localmente con un repositorio de GitHub, GitLab, Bitbucket o un servidor propio.
• Si el repositorio es privado, necesitarás configurar acceso SSH o credenciales antes.
• Para clonar en una carpeta con nombre diferente: git clone <url> nombre-carpeta
• Para clonar solo la rama principal sin historial completo (más rápido en repos grandes): git clone --depth 1 <url>

3. Ver el estado del área de trabajo

git status

Muestra qué archivos han cambiado, cuáles están preparados para el próximo commit y cuáles no están siendo rastreados por Git.

• Cuándo usarlo: antes de cualquier git add o git commit para saber exactamente en qué estado está tu área de trabajo. Es el comando de orientación por excelencia.
• Versión compacta: git status -s

4. Añadir archivos al área de preparación (staging)

git add archivo-o-carpeta

Prepara los cambios seleccionados para incluirlos en el próximo commit. No guarda nada permanentemente — solo mueve los cambios al área de staging.

• git add . → añade todos los cambios de la carpeta actual.
• git add -p → modo interactivo: te permite elegir qué fragmentos de cada archivo añadir (útil para commits más precisos).
• Importante: si modificas el archivo después de hacer git add, necesitas ejecutarlo de nuevo para incluir los últimos cambios.

5. Crear un commit

git commit -m "Mensaje descriptivo"

Registra de forma permanente en el historial del repositorio los cambios que están en el área de staging.

• git commit -am "msg" → hace git add de todos los archivos rastreados y crea el commit en un solo paso (no incluye archivos nuevos sin rastrear).
• git commit --amend → modifica el último commit (mensaje o contenido). Úsalo solo si aún no has hecho push.
• Buena práctica: mensajes en imperativo y en el idioma del equipo: “Añadir validación de formulario”, no “añadido formulario” ni “cambios”.

6. Comparar cambios

git diff

Muestra las diferencias entre el área de trabajo y el área de staging (cambios aún no preparados).

• git diff --staged → muestra diferencias entre staging y el último commit (lo que se va a commitear).
• git diff rama1..rama2 → compara el contenido de dos ramas.
• git diff commit1..commit2 → compara dos commits específicos usando sus IDs.

Comandos de ramas en Git

7. Gestionar ramas

git branch
git branch nueva-rama
git branch -d rama-a-borrar

• Sin argumentos: lista las ramas locales. La rama activa aparece marcada con *.
• git branch -a → muestra también las ramas remotas.
• git branch -m nombre-nuevo → renombra la rama actual.
• git branch -d → elimina una rama solo si ya está fusionada. Usa -D para forzar el borrado.

8. Cambiar de rama (checkout / switch)

git checkout nombre-de-rama
git checkout -b nueva-rama

Cambia la rama activa. Con -b crea la rama y cambia a ella en un solo paso.

• En versiones de Git ≥ 2.23 existe el comando más explícito: git switch nombre-de-rama (para cambiar) y git switch -c nueva-rama (para crear y cambiar).
• git checkout -- archivo → restaura un archivo concreto al estado del último commit, descartando los cambios locales.
• Precaución: si tienes cambios sin commitear al cambiar de rama, Git puede pedirte que los guardes con git stash primero.

9. Fusionar ramas

git merge rama-a-fusionar

Combina el historial de la rama indicada con la rama activa actualmente.

• Cuándo usarlo: cuando el trabajo de una rama de feature está terminado y quieres incorporarlo a main o develop.
• Si hay conflictos, Git marca los archivos afectados. Debes resolverlos manualmente, hacer git add de los archivos resueltos y luego git commit.
• git merge --no-ff rama → crea siempre un commit de merge, aunque no sea necesario (útil para mantener el historial explícito).
• git merge --abort → cancela el merge en curso si hay conflictos que no quieres resolver ahora.

Comandos de sincronización con el remoto

10. Descargar cambios sin fusionar

git fetch

Descarga las actualizaciones del repositorio remoto (nuevas ramas, nuevos commits) pero no modifica tu área de trabajo ni tu rama activa. Es la forma segura de ver qué hay en el remoto antes de integrar.

• git fetch origin → descarga del remoto llamado origin.
• git fetch --all → descarga de todos los remotos configurados.

11. Descargar y fusionar cambios

git pull

Equivale a git fetch + git merge. Trae los cambios del remoto y los integra directamente en la rama activa.

• git pull --rebase → en lugar de crear un commit de merge, reaplica tus commits locales encima de los remotos. Produce un historial más lineal y limpio.
• Error habitual: si tienes commits locales que divergen del remoto, git pull puede crear un merge commit no deseado. Usa --rebase para evitarlo.

12. Enviar cambios al remoto

git push origin rama

Sube tus commits locales a la rama indicada del repositorio remoto.

• git push -u origin rama → vincula la rama local a la remota para que futuros git push y git pull no necesiten especificar el remoto y la rama.
• git push --force-with-lease → fuerza el push de forma más segura que --force: falla si alguien más subió cambios al remoto desde tu último fetch.
• Precaución con --force: reescribe el historial remoto. Nunca lo uses en ramas compartidas como main.

Historial, diagnóstico y búsqueda

13. Revisar el historial de commits

git log

Lista los commits de la rama activa con autor, fecha y mensaje completo.

• git log --oneline → formato compacto, un commit por línea. El más usado en el día a día.
• git log --oneline --graph --all → visualiza el árbol de ramas en el terminal.
• git log --after="2025-01-01" --before="2025-03-31" → filtra por rango de fechas.
• git log --grep="texto" → busca commits cuyo mensaje contenga el texto.
• git log -- archivo → muestra solo los commits que tocaron un archivo específico.

14. Ver quién cambió cada línea (blame)

git blame archivo

Muestra el archivo línea por línea con el autor, la fecha y el ID del commit que introdujo cada cambio.

• Cuándo usarlo: para entender por qué se escribió cierta línea de código o quién introdujo un bug.
• git blame -L 20,40 archivo → limita la salida a las líneas 20-40.

15. Buscar dentro del código

git grep "texto"

Busca cadenas o patrones en los archivos rastreados por Git. Es más rápido que grep normal porque solo busca en archivos del repositorio, ignorando node_modules, .git/, etc.

• git grep -i "texto" → búsqueda sin distinguir mayúsculas/minúsculas.
• git grep "texto" -- "*.php" → busca solo en archivos PHP.

16. Resumen de commits por autor

git shortlog

Agrupa los commits por autor con un recuento. Muy útil para generar changelogs o ver la distribución de trabajo en el equipo.

• git shortlog -sn → muestra solo el número de commits por autor, ordenados de mayor a menor.

Deshacer cambios y recuperar versiones

17. Revertir un commit (seguro)

git revert commitID

Crea un nuevo commit que deshace los cambios del commit indicado, sin borrar ni modificar el historial existente. Es la forma segura de revertir en ramas compartidas.

• Cuándo usarlo: cuando necesitas deshacer algo que ya está en el remoto y otros compañeros pueden haber descargado.
• git revert --no-commit commitID → aplica la reversión sin crear el commit inmediatamente, para que puedas revisarla antes.

18. Resetear al estado de un commit anterior

git reset --hard HEAD
git reset --hard commitID

Mueve la rama activa a un commit anterior y descarta permanentemente todos los cambios posteriores.

• git reset --soft commitID → mueve el puntero de la rama al commit indicado pero mantiene los cambios en el área de staging (útil para “descomprimir” varios commits en uno).
• git reset --mixed commitID → mueve el puntero y saca los cambios del staging, pero los mantiene en el área de trabajo.
• Precaución: --hard es irreversible para los cambios no commiteados. Nunca lo uses en ramas que otros compañeros hayan descargado.

19. Guardar cambios temporales (stash)

git stash save "mensaje"
git stash list
git stash apply
git stash pop

Guarda los cambios sin commitear en una pila temporal para que puedas cambiar de rama o contexto sin perderlos.

• git stash → guarda con un mensaje automático.
• git stash pop → aplica el último stash guardado y lo elimina de la pila.
• git stash apply stash@{2} → aplica un stash específico sin eliminarlo de la pila.
• git stash drop stash@{0} → elimina un stash específico sin aplicarlo.
• git stash -u → incluye también archivos no rastreados (nuevos sin git add).

Mantenimiento y configuración

20. Eliminar archivos del seguimiento de Git

git rm archivo

Elimina el archivo tanto del área de trabajo como del índice de Git. El cambio quedará preparado para el siguiente commit.

• git rm -r carpeta/ → elimina una carpeta y su contenido recursivamente.
• git rm --cached archivo → deja de rastrear el archivo en Git pero lo mantiene en disco. Útil para añadirlo al .gitignore a posteriori.

21. Limpiar archivos no rastreados

git clean -n
git clean -fd

• -n (o --dry-run) → solo lista lo que se eliminaría, sin borrar nada. Úsalo siempre primero.
• -f → fuerza la limpieza (obligatorio para que git clean borre algo).
• -d → incluye también carpetas no rastreadas.
• -x → incluye archivos ignorados por .gitignore (útil para limpiar builds o caches).

22. Configurar Git

git config --global user.name "Tu Nombre"
git config --global user.email "tu@email.com"

Establece la identidad que aparecerá en todos tus commits. La opción --global aplica a todos los repositorios del sistema; sin ella, la configuración es solo para el repositorio actual.

• git config --list → muestra todas las configuraciones activas.
• git config --global core.editor "code --wait" → establece VS Code como editor por defecto para mensajes de commit y resolución de conflictos.
• git config --global init.defaultBranch main → establece main como nombre de rama inicial en todos los repos nuevos.

Flujo de trabajo Git típico paso a paso

Los comandos anteriores cobran sentido dentro de un flujo de trabajo real. Este es el ciclo habitual al trabajar en una feature o corrección:

1. Actualizar la rama principal antes de empezar:

   git checkout main
   git pull

2. Crear una rama de trabajo:

   git checkout -b feature/nombre-de-la-feature

3. Desarrollar y hacer commits regularmente:

   git status
   git add .
   git commit -m "Descripción clara del cambio"

4. Subir la rama al remoto:

   git push -u origin feature/nombre-de-la-feature

5. Abrir una Pull Request / Merge Request en GitHub, GitLab o Bitbucket para revisión del equipo.
6. Fusionar en main una vez aprobada:

   git checkout main
   git merge feature/nombre-de-la-feature
   git push

7. Eliminar la rama de feature:

   git branch -d feature/nombre-de-la-feature
   git push origin --delete feature/nombre-de-la-feature

Errores comunes en Git y cómo resolverlos

«Your local changes would be overwritten by merge»

Tienes cambios sin commitear en archivos que el merge también va a modificar. Git se niega a sobrescribirlos. Solución: guarda los cambios con git stash, haz el merge o pull, y luego recupera tus cambios con git stash pop.

«fatal: refusing to merge unrelated histories»

Ocurre al intentar fusionar dos repositorios que no comparten ningún commit en común (por ejemplo, un repo local iniciado con git init con uno remoto que ya tenía commits). Solución: git pull origin main --allow-unrelated-histories.

«error: failed to push some refs»

El remoto tiene commits que tú no tienes localmente. Necesitas primero incorporar esos cambios. Solución: git pull --rebase origin main y luego git push.

Conflictos de merge no resueltos

Git marca los archivos con conflicto con las secciones <<<<<<<, ======= y >>>>>>>. El proceso para resolverlos es: editar los archivos manualmente para dejar el contenido correcto, ejecutar git add archivo-resuelto por cada archivo y finalmente git commit para completar el merge.

Commit con mensaje incorrecto (antes de hacer push)

Si el último commit aún no está en el remoto, puedes corregirlo con git commit --amend -m "Mensaje correcto".

Accidentalmente commiteé en la rama equivocada

Si aún no has hecho push: cambia a la rama correcta, ejecuta git cherry-pick <commitID> para copiar el commit allí, y luego vuelve a la rama equivocada y deshaz el commit con git reset --hard HEAD~1.

Preguntas frecuentes sobre comandos Git

¿Cuál es la diferencia entre git pull y git fetch?

git fetch descarga las actualizaciones del remoto pero no modifica tu área de trabajo ni tu rama activa — solo actualiza las referencias remotas locales. git pull hace lo mismo pero además fusiona (o rebasa) esos cambios en tu rama actual. fetch es más seguro cuando quieres revisar qué cambió antes de integrar.

¿Cuál es la diferencia entre git merge y git rebase?

git merge une dos ramas creando un nuevo commit de merge, preservando el historial completo con todas las bifurcaciones. git rebase reaplica los commits de tu rama encima de otra, produciendo un historial lineal más limpio pero reescribiendo los IDs de commit. Regla general: usa merge en ramas compartidas (main, develop) y rebase en ramas de feature locales antes de hacer push.

¿Cuál es la diferencia entre git revert y git reset?

git revert crea un nuevo commit que deshace los cambios de otro commit, sin modificar el historial existente. Es seguro en ramas compartidas. git reset mueve el puntero de la rama hacia atrás, reescribiendo el historial. Solo debe usarse en commits que aún no están en el remoto.

¿Cómo ver todos los comandos disponibles de Git?

Ejecuta git help para el resumen básico, git help -a para el listado completo de comandos, o git help <comando> para la documentación detallada de un comando específico. Por ejemplo: git help log.

¿Cómo deshacer el último git add sin perder los cambios?

Con git reset HEAD archivo (o git restore --staged archivo en Git ≥ 2.23). Esto saca el archivo del área de staging pero mantiene los cambios en el área de trabajo.

¿Cómo eliminar una rama remota?

Con git push origin --delete nombre-de-rama. Para eliminar también la referencia local de esa rama remota: git fetch --prune.

¿Qué es el archivo .gitignore y cómo funciona?

Es un archivo de texto en la raíz del repositorio que le indica a Git qué archivos o carpetas debe ignorar (no rastrear). Se usa para excluir archivos de configuración local, dependencias (node_modules/, vendor/), builds compilados, archivos con credenciales, etc. Cada línea es un patrón: *.log ignora todos los archivos .log; /dist ignora la carpeta dist en la raíz.