git status: cómo leer lo que Git te está diciendo

Cuando empiezas con Git, git status es el primer comando que aprendes y el último que entiendes. Lo ejecutas, aparece un bloque de texto en inglés con secciones que no sabes leer, y sigues copiando comandos con la esperanza de que funcionen. La dificultad real es traducir su salida a algo con lo que actuar. En este post recorro esa salida línea a línea para que sepas exactamente en qué estado está tu repo y qué hacer a continuación.

Para seguir esto necesitas haber instalado Git y haber hecho al menos un commit siguiendo algún tutorial. Si aún no llegas ahí, aprende primero qué es Git y cómo se inicia un repositorio, y vuelve luego.

¿Qué es git status y por qué conviene ejecutarlo primero?

git status es un comando de solo lectura: te informa del estado de tu repositorio sin cambiar absolutamente nada. No borra archivos, no guarda commits, no envía nada al servidor. Puedes ejecutarlo mil veces seguidas y el resultado será idéntico. Por eso es seguro y por eso lo verás en todos los flujos de trabajo antes de cualquier otra acción.

Piénsalo como el salpicadero del coche. No conduce por ti, pero te dice a qué velocidad vas, cuánta gasolina te queda y si hay una luz encendida. Antes de hacer git add, antes de git commit, antes de git push, miras el salpicadero. Si adquieres el hábito de ejecutar git status cada vez que dudas, te ahorrarás la mayoría de los sustos típicos de principiante: commits vacíos, archivos que se quedan fuera, cambios que creías haber guardado y no.

La salida parece intimidante porque está en inglés y usa vocabulario propio. Pero siempre responde a las mismas dos preguntas: en qué rama estás y qué ha pasado con tus archivos.

Los tres estados de un archivo en Git

Cada archivo dentro de un repositorio Git está en uno de tres estados, y toda la salida de git status gira alrededor de esta idea. Entender esto primero hace que el resto se lea solo.

Un archivo untracked (sin seguimiento) es uno que existe en tu carpeta pero que Git todavía no controla. Acabas de crearlo y Git lo ve, pero no le está haciendo el seguimiento. No entrará en ningún commit hasta que se lo digas.

Un archivo unstaged (modificado, sin preparar) es uno que Git ya controla y que has cambiado desde el último commit, pero cuyos cambios aún no has marcado para guardar. Git sabe que lo tocaste. Simplemente todavía no le has dicho “esto quiero que entre en el próximo commit”.

Un archivo staged (preparado) es uno cuyos cambios has marcado con git add y que entrará en el próximo commit. Es una sala de espera. El archivo está listo, pero aún no forma parte del historial: eso ocurre cuando haces git commit.

La confusión más habitual es creer que git add guarda el archivo. No lo guarda de forma permanente. Solo lo mueve a esa sala de espera. Si quieres el detalle de cómo se mueve un archivo de un estado a otro, lo tienes en git add, commit y push explicados. Aquí tienes los tres estados de un vistazo:

Estado	Qué significa	Cómo aparece en git status	Qué comando lo mueve al siguiente estado
Untracked	Git aún no lo sigue	En “Untracked files:”, o ?? en el formato corto	git add lo pasa a staged
Unstaged (modificado)	Git lo sigue y tiene cambios sin preparar	En “Changes not staged for commit:”, o M en la segunda columna	git add lo pasa a staged
Staged (preparado)	Sus cambios entrarán en el próximo commit	En “Changes to be committed:”, o M/A en la primera columna	git commit lo guarda en el historial

Con estos tres nombres en la cabeza, la salida completa deja de ser un muro de texto.

¿Cómo se lee la salida sección por sección?

La salida se divide en la línea de la rama y luego una sección por cada estado que tenga archivos. Cada sección lista los archivos y, entre paréntesis, la propia Git te sugiere el comando para actuar. Mira un repo con los tres estados a la vez:

On branch main
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
	new file:   estilos.css

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	modified:   README.md

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	notas.txt

Vamos de arriba abajo. La primera línea, On branch main, te dice en qué rama trabajas (volveré a ella en la siguiente sección).

Después viene Changes to be committed:. Todo lo que aparezca aquí entrará en tu próximo commit. En el ejemplo es estilos.css, marcado como new file porque es un archivo nuevo que ya preparaste con git add. En la terminal esta sección sale en verde. Si ves algo aquí, git commit lo guardará.

Luego Changes not staged for commit:. Son archivos que Git ya controla y que has modificado, pero cuyos cambios no has preparado. Aquí README.md aparece como modified. Esta sección sale en rojo, y ese rojo asusta a mucha gente. No es un error: solo significa “hay cambios que Git ve pero que todavía no van a viajar en el commit”. Si quieres que entren, git add README.md.

Por último Untracked files:. Archivos que existen en tu carpeta pero de los que Git no sabe nada, como notas.txt. Este es el punto donde más gente tropieza: haces un commit, das por hecho que todo se guardó, y semanas después descubres que el archivo nuevo nunca entró porque seguía untracked. Git te lo estaba diciendo. Si quieres incluirlo, git add notas.txt lo convierte en un archivo preparado.

Fíjate en que cada sección lleva su propia pista entre paréntesis. Git literalmente te dice qué comando usar. Leer esas pistas es la mitad del trabajo.

¿Qué significa la línea de la rama: ahead, behind y up to date?

La primera línea siempre indica tu rama, y a menudo la sigue una segunda línea que compara tu copia local con el servidor remoto. Cuando tu rama está sincronizada con el remoto, ves esto:

On branch main
Your branch is up to date with 'origin/main'.

nothing to commit, working tree clean

Your branch is up to date with 'origin/main'. significa que tu rama local tiene exactamente los mismos commits que la del servidor (origin es el nombre por defecto del remoto). No debes nada, no te falta nada.

Cuando haces commits en local pero todavía no los has enviado, tu rama va por delante:

On branch main
Your branch is ahead of 'origin/main' by 2 commits.
  (use "git push" to publish your local commits)

nothing to commit, working tree clean

ahead of 'origin/main' by 2 commits quiere decir que tienes dos commits guardados en tu máquina que el servidor todavía no conoce. La solución la sugiere Git misma: git push para publicarlos.

El caso contrario es que el servidor tenga commits que tú no. Por ejemplo, un compañero subió cambios:

On branch main
Your branch is behind 'origin/main' by 1 commit, and can be fast-forwarded.
  (use "git pull" to update your local branch)

nothing to commit, working tree clean

behind 'origin/main' by 1 commit significa que te falta un commit que ya está en el remoto. git pull lo trae a tu copia local. Esta línea es tu recordatorio de cuándo hacer push y cuándo hacer pull, sin tener que adivinarlo.

El caso limpio: nothing to commit, working tree clean

nothing to commit, working tree clean es la frase que quieres ver: no hay ningún cambio pendiente y todo tu directorio coincide con el último commit. Ya lo has visto asomar en los ejemplos anteriores, debajo de la línea de la rama.

El working tree (árbol de trabajo) es simplemente la carpeta de archivos con la que trabajas ahora mismo. Que esté “clean” significa que no hay diferencias entre lo que tienes delante y lo que guardaste en tu último commit. No hay nada modificado, ni archivos nuevos sin seguir, ni cambios a medias.

Es la meta después de cada commit. Si acabas de guardar tu trabajo y git status te dice esto, tienes la tranquilidad de que no te dejas nada fuera. Es un buen momento para hacer push o para cambiar de rama sin arrastrar cambios sueltos. Y si quieres revisar qué has guardado hasta ahora, el siguiente comando que conviene dominar es git log para ver el historial.

git status -s: la versión corta cuando ya lo entiendes

git status -s (o git status --short) muestra lo mismo comprimido en una línea por archivo, usando dos columnas de códigos. Cuando ya sabes leer la versión larga, esta te ahorra tiempo. El mismo repo mezclado de antes se ve así:

 M README.md
A  estilos.css
?? notas.txt

Fíjate en las dos columnas de la izquierda, la posición XY. La primera columna (X) es el estado en el área de preparación (staged); la segunda columna (Y) es el estado en tu working tree (sin preparar). Los códigos más habituales son M para modificado, A para añadido, D para borrado y ?? para untracked ^[1].

Léelo columna a columna. En M README.md la primera posición está en blanco y la M está en la segunda: el archivo está modificado pero sin preparar. En A estilos.css la A está en la primera columna: es un archivo nuevo ya preparado para el commit. Y ?? marca notas.txt como untracked. Es exactamente la misma información que la salida larga, solo que en tres líneas en lugar de quince.

Errores comunes al leer git status

• Confundir “staged” con “committed” (la sala de espera de arriba): si cambias de rama sin hacer git commit, esos cambios se quedan preparados pero fuera del historial. Confírmalo con git log --oneline: si tu cambio no sale en la lista, todavía no está guardado.
• Asustarse del rojo de “Changes not staged for commit”: solo marca cambios que aún no has preparado, y desaparece en cuanto haces git add. Vuelve a ejecutar git status y verás esos archivos pasar a la sección verde.
• Ignorar la sección de untracked: un archivo bajo “Untracked files:” no viaja en el commit por mucho que hagas git commit. Cada vez que crees un archivo nuevo, ejecuta git status y compruébalo antes de dar el commit por cerrado.

Checklist para leer cualquier salida de git status

• Mira primero la línea de la rama: sabes en qué rama estás
• Comprueba si dice up to date, ahead o behind para saber si toca push o pull
• Revisa “Changes to be committed”: eso es lo que va a entrar en el próximo commit
• Revisa “Changes not staged for commit” y decide qué preparar con git add
• Revisa “Untracked files” para no dejarte ningún archivo nuevo fuera
• Confirma que llegas a “nothing to commit, working tree clean” tras el commit

Practica esto hasta que te salga solo

Leer git status de un vistazo es de esas destrezas que solo se afianzan repitiéndolas con un repo delante. Si quieres practicarlo paso a paso, con ejercicios guiados que te ponen distintas salidas y te piden decidir qué hacer, lo trabajamos a fondo en el curso Git de cero a profesional.

Un concepto nuevo cada semana

Suscribirme

Fuentes

1. Documentación oficial de Git: git status. Códigos del formato corto (columnas XY: M, A, D, ??). Los nombres exactos de las secciones del formato largo (“Changes to be committed:”, “Changes not staged for commit:”, “Untracked files:”) se comprueban ejecutando git status.

Preguntas Frecuentes

¿git status modifica algo en mi repositorio?

No. git status es un comando de solo lectura: solo informa del estado actual y no cambia archivos, ni prepara nada, ni crea commits. Puedes ejecutarlo tantas veces como quieras sin ningún riesgo.

¿Qué diferencia hay entre staged y committed?

Staged significa que un cambio está preparado para el próximo commit, esperando en el área de preparación tras un git add. Committed significa que ya está guardado en el historial del repositorio tras un git commit. Preparar no guarda de forma permanente: es el paso previo. Un archivo staged todavía puede quedarse fuera del historial si nunca haces el commit.

¿Por qué mi archivo nuevo no aparece en el commit?

Casi siempre porque el archivo estaba untracked y no lo preparaste. Git no incluye archivos nuevos en un commit de forma automática: aparecen bajo “Untracked files:” hasta que ejecutas git add nombre-del-archivo. Si haces commit sin ese paso, el archivo se queda en tu carpeta pero fuera del historial.

¿Qué significa “ahead of origin”?

Significa que tienes commits en tu copia local que todavía no están en el servidor remoto. La línea Your branch is ahead of 'origin/main' by N commits te dice cuántos commits tienes pendientes de enviar. Se resuelven con git push.

¿Qué es el working tree?

El working tree, o árbol de trabajo, es la carpeta de archivos con la que trabajas en este momento. Cuando git status dice “working tree clean”, quiere decir que no hay diferencias entre esos archivos y tu último commit. Es la foto de tu carpeta comparada con el último commit guardado.