Ana tiene su repositorio y Bruno tiene su clon. A partir de aquí, los dos hacen exactamente lo mismo cada día, decenas de veces: editan ficheros, deciden qué cambios agrupar y los registran en el historial. Ese ciclo de tres pasos —editar, preparar, confirmar— es el latido de Git. Todo lo demás del curso (ramas, fusiones, rebase, remotos) se construye encima.

En el módulo 1 aprendiste la teoría: las tres zonas (directorio de trabajo, área de preparación y repositorio) y los tres estados (modificado, preparado, confirmado). En esta lección esa teoría se pone en movimiento. Vamos a ver cómo un fichero viaja de una zona a otra, qué estados atraviesa desde que Git no lo conoce hasta que queda confirmado, y cómo git status te dice en todo momento exactamente dónde estás.

El objetivo es que, al terminar, puedas mirar la salida de git status en cualquier repositorio del mundo y saber en un segundo qué está pasando y cuál es el siguiente comando razonable.

1. El ciclo de tres pasos
2. Las tres zonas en movimiento
3. El ciclo de vida de un fichero
4. git status: la brújula
5. git status --short: la forma abreviada y su tabla de códigos
6. Ficheros que no quieres versionar: .gitignore en dos minutos
7. Una sesión de trabajo completa de Ana, narrada
8. El ciclo en la práctica diaria

El flujo de trabajo básico de Git tiene esta forma:

Tres pasos, dos comandos. Lo que desconcierta al principio es el paso intermedio: ¿por qué no basta con "guardar los cambios"? ¿Para qué existe el área de preparación?

La respuesta es que separa dos decisiones distintas:

• Editar responde a "¿qué he cambiado?". Es trabajo.
• Preparar responde a "¿qué de lo que he cambiado forma una unidad con sentido?". Es criterio.

Imagina que Ana pasa la mañana arreglando un fallo en app.js y, de paso, corrige una falta de ortografía en README.md y ajusta un color en estilos.css. Son tres cosas sin relación entre sí. Sin área de preparación, tendría dos opciones malas: meterlo todo en una confirmación revuelta, o ir deshaciendo cambios a mano para confirmarlos por separado. Con el área de preparación, elige: prepara solo app.js, confirma, prepara README.md, confirma, y así.

El resultado es un historial donde cada confirmación cuenta una sola cosa. Cuando dentro de seis meses alguien busque por qué se rompió el borrado de tareas, encontrará una confirmación que habla exactamente de eso y no de tres asuntos mezclados.

Esta idea —el commit atómico— es tan importante que la desarrollamos a fondo en la siguiente lección, Preparando y Confirmando Cambios.

Recuperemos el esquema de Terminología Básica de Git, esta vez con los comandos que mueven la información de una zona a otra:

Tres reglas que conviene tener grabadas:

1. Solo se confirma lo que está preparado. git commit no mira el directorio de trabajo: fotografía el área de preparación. Un cambio que no hayas preparado no entra, por muy guardado que esté en el disco.
2. El área de preparación es un estado, no una cola. No es una lista de comandos pendientes; es una versión completa del proyecto. Contiene el contenido íntegro de cada fichero, no "las líneas que has añadido".
3. Las tres zonas pueden tener contenidos distintos del mismo fichero a la vez. Es la fuente de confusión número uno de los principiantes, y también la fuente del poder de Git. Lo veremos en acción en la sesión narrada.

Cada fichero de tu carpeta está, en cada momento, en uno de cuatro estados. Este diagrama los recoge todos y muestra qué comando produce cada transición:

Veamos los cuatro estados uno a uno:

Hay una distinción de fondo que conviene fijar: rastreado frente a no rastreado. Un fichero está rastreado si aparece en la última confirmación o en el área de preparación; es decir, si Git lo conoce. Los tres estados "sin modificar", "modificado" y "preparado" son variantes de rastreado. "Sin seguimiento" es la única categoría de fuera.

Esta distinción importa porque muchos comandos actúan solo sobre ficheros rastreados. Por ejemplo, git commit -a prepara automáticamente los ficheros modificados, pero no los que están sin seguimiento; hay que añadirlos a mano al menos una primera vez.

Fíjate en la transición Preparado --> Modificado del diagrama. Es real y ocurre constantemente:

1. Ana modifica app.js y lo prepara con git add app.js. El área de preparación guarda esa versión.
2. Ana sigue trabajando y vuelve a tocar app.js. Ahora el disco tiene una versión más nueva que el área de preparación.

Resultado: app.js aparece en las dos secciones de git status, la de preparados y la de no preparados. No es un error ni una anomalía: hay dos versiones distintas guardadas en dos zonas distintas, y si Ana confirmara ahora, entraría la preparada (la más antigua), no la del disco.

Si tuvieras que quedarte con un solo comando de Git, sería este. No modifica nada, es instantáneo y responde siempre a las mismas cuatro preguntas: en qué rama estás, cómo estás respecto al remoto, qué hay preparado y qué hay pendiente.

Vamos a leer una salida completa, con todos los casos a la vez:

Diseccionémoslo bloque a bloque:

Cabecera.

• On branch main: la rama actual. Es lo primero que hay que mirar; equivocarse de rama es un clásico.
• Your branch is up to date with 'origin/main': comparación con la rama de seguimiento del remoto. Solo aparece si existe un remoto configurado, como en el clon de Bruno. Puede decir también ahead by N commits o behind by N commits. Lo desarrollaremos en el módulo 4.

Changes to be committed — el área de preparación. Todo lo que aparezca aquí entrará en el próximo git commit. Cada línea lleva un verbo que indica el tipo de cambio: modified, new file, deleted, renamed.

Changes not staged for commit — cambios en el directorio de trabajo sobre ficheros que Git ya rastrea, pero que no entrarán en el próximo commit. Ojo: aquí solo aparecen ficheros rastreados.

Untracked files — ficheros que Git ve por primera vez. Nunca entrarán en ninguna confirmación hasta que hagas git add explícitamente.

Las sugerencias entre paréntesis. Git te dice, en cada sección, cómo avanzar y cómo retroceder. Merece la pena leerlas: son la mejor documentación en línea que existe.

Todo confirmado, nada pendiente. Las tres zonas coinciden. Es el estado ideal para cambiar de tarea.

No hay nada preparado. Si hicieras git commit ahora, Git se negaría porque no habría nada que confirmar.

Has trabajado, pero no has preparado nada. La última línea es la advertencia: git commit a secas no haría nada.

La salida larga es excelente para aprender, pero cansa cuando la consultas cuarenta veces al día. La forma corta cabe en una pantalla:

La clave está en que hay dos columnas antes del nombre del fichero, y significan cosas distintas:

• Columna 1 (izquierda): el estado en el ÁREA DE PREPARACIÓN.
• Columna 2 (derecha): el estado en el DIRECTORIO DE TRABAJO.

Entender esto convierte una salida críptica en información precisa. Los códigos posibles:

Y ahora las combinaciones que realmente aparecen en el día a día:

Aplicado al ejemplo anterior:

• M estilos.css → modificado y preparado. Entrará en el commit.
• A .gitignore → nuevo y preparado. Entrará.
• M app.js → modificado pero sin preparar. No entrará. Fíjate en el espacio inicial: es significativo.
• D antiguo.js → borrado del disco, sin preparar. El commit seguiría incluyendo el fichero.
• ?? notas.txt → sin seguimiento. No entrará.

Truco de lectura. Coloca el dedo sobre la primera columna: lo que queda tapado es "lo que hay en el disco". Descúbrela: lo que ves ahí es "lo que va a entrar en el commit".

Una variante muy útil añade la información de rama:

La primera línea resume rama actual, rama de seguimiento y divergencia. Con -sb tienes en cinco líneas todo lo que la salida larga cuenta en veinticinco.

Hay un problema práctico con Untracked files: muchas carpetas de proyecto acumulan ficheros que nunca deben versionarse. Dependencias instaladas, resultados de compilación, ficheros temporales del editor, credenciales, ficheros del sistema operativo… Si aparecen todos en cada git status, la señal se pierde entre el ruido y acabas ignorando la salida del comando, que es justo lo que no quieres.

La solución es un fichero llamado .gitignore en la raíz del proyecto, con un patrón por línea:

Los ficheros que coincidan con esos patrones desaparecen de git status y no se pueden añadir por accidente con git add .. El propio .gitignore sí se versiona: es parte del proyecto y debe ser igual para todo el equipo, lo cual resuelve de paso un conflicto histórico entre los tres sistemas operativos de Ana, Bruno y Carla (.DS_Store en macOS, Thumbs.db en Windows).

Dos matices que evitan la frustración más común:

• .gitignore solo afecta a ficheros sin seguimiento. Si un fichero ya está rastreado, añadirlo al .gitignore no lo saca del proyecto: hay que quitarlo del índice explícitamente, algo que veremos en Preparando y Confirmando Cambios.
• Escríbelo pronto, idealmente antes del primer git add, como vimos en Creando un Repositorio.

Con esto tienes lo necesario para trabajar. Los patrones avanzados, las negaciones con !, los .gitignore por subdirectorio, el fichero global y .git/info/exclude se tratan a fondo en Ignorando Archivos con .gitignore.

Vamos a seguir a Ana durante una tarde entera. Es martes y quiere añadir un contador de tareas pendientes a gestor-tareas. Punto de partida:

Todo limpio: las tres zonas coinciden con la última confirmación. Es el punto de partida correcto para empezar algo nuevo.

Añade el elemento del contador en index.html:

Le da estilo en estilos.css:

Y añade la lógica en app.js:

De paso, arranca el proyecto para probarlo, lo que genera un fichero de registro, y abre un bloc de notas con ideas sueltas.

Cinco entradas: tres ficheros del proyecto modificados y dos ficheros nuevos que no quiere versionar. La última línea le recuerda que, tal como está, git commit no haría nada.

Antes de preparar nada, escribe el .gitignore:

depuracion.log y notas.txt han desaparecido. Ahora la salida solo contiene señal. Fíjate en las tres líneas que empiezan por espacio: columna 1 vacía significa que nada de eso entraría todavía en un commit.

La M y la A se han desplazado a la primera columna. Los cuatro ficheros están preparados. En la forma larga:

Ha desaparecido la sección de "no preparados": no queda nada pendiente en el directorio de trabajo.

Probando la página, Ana ve que el contador dice "1 tareas pendientes". Corrige app.js para que el singular funcione:

Y consulta de nuevo:

Ahí está el caso interesante: MM app.js. El fichero aparece con M en las dos columnas. Significa exactamente esto:

• Columna 1 (M): hay una versión de app.js preparada — la de las 17:45, sin la corrección del singular.
• Columna 2 (M): el fichero del disco es distinto de esa versión preparada — tiene la corrección.

En la forma larga se ve todavía más claro, porque el mismo fichero sale dos veces:

Si Ana confirmara ahora, entraría la versión con la errata. Es la trampa clásica de Git y la razón por la que conviene mirar git status justo antes de confirmar.

La segunda columna de app.js vuelve a estar vacía. Ahora la versión preparada es la buena.

Vuelta al punto de partida. Las tres zonas coinciden otra vez, ahora sobre una confirmación nueva. Y comprobemos que los ficheros ignorados siguen ahí, simplemente invisibles para Git:

Están en el disco, marcados como ignorados. Git los ve y decide, deliberadamente, no molestarte con ellos.

Con el flujo interiorizado, el día a día se reduce a un puñado de hábitos:

El bucle mínimo, que ejecutarás miles de veces:

Cuatro hábitos que marcan la diferencia:

1. git status antes de empezar. Saber si arrancas de un árbol limpio o si te dejaste algo a medias ayer evita mezclar dos tareas en una confirmación.
2. git status antes de confirmar. Es el único momento en que puedes detectar un MM o un fichero olvidado. Cuesta un segundo.
3. Confirma pronto y a menudo. Una confirmación no es una entrega ni una publicación: es un punto de guardado. Un historial de veinte confirmaciones pequeñas es infinitamente más útil que uno de dos confirmaciones gigantes.
4. Termina el día con el árbol limpio siempre que puedas. Si no es posible, al menos deja anotado en qué estabas.

Qué hacer cuando el bucle se rompe. Estas son las situaciones más frecuentes y su salida; todas se desarrollan en la siguiente lección:

• Confirmar sin mirar git status. El caso MM —un fichero preparado y luego vuelto a modificar— hace que entre en el historial una versión que no es la que tienes delante. Un vistazo al estado antes de confirmar lo evita.
• Creer que git add "guarda" el fichero. git add no guarda nada de forma permanente: copia el contenido actual al área de preparación. Si sigues editando, esa copia se queda vieja.
• Olvidar que git commit -a no incluye ficheros sin seguimiento. La opción -a prepara automáticamente los ficheros rastreados modificados o borrados. Un fichero nuevo hay que añadirlo con git add al menos una vez.
• Ignorar la sección Untracked files. Es donde se esconde el fichero nuevo que olvidaste añadir y por el que el proyecto no compila en la máquina de tu compañero.
• Malinterpretar las dos columnas de --short. M (espacio y eme) y M (eme y espacio) significan cosas opuestas. Si dudas, usa la forma larga.
• Trabajar con git status lleno de ruido. Si tienes cuarenta ficheros sin seguimiento que nunca vas a versionar, escribe el .gitignore. Un status legible es una herramienta; uno ilegible es un estorbo.
• Añadir .gitignore demasiado tarde. Si el fichero ya está rastreado, ignorarlo no tiene efecto. Hay que sacarlo del índice primero.
• Consejo: define un alias corto para el estado, ya que lo usarás constantemente: git config --global alias.s "status -sb". Después basta con git s. Los alias se tratan en Git Log y Alias.
• Consejo: si git status tarda mucho en un proyecto grande, suele ser síntoma de que hay demasiados ficheros sin seguimiento (dependencias, artefactos de compilación). Un buen .gitignore lo arregla.

Un repositorio muestra esta salida:

Responde razonadamente:

1. ¿Qué ficheros entrarán en el próximo git commit (sin usar -a) y con qué cambio?
2. ¿Qué le pasa a app.js? Si se confirma ahora, ¿qué versión queda registrada?
3. index.html se ha borrado del disco. ¿Desaparecerá del proyecto al confirmar?
4. ¿Cuántas confirmaciones tiene esta rama por delante del remoto?
5. Escribe la secuencia de comandos que dejaría el estado listo para que todo lo borrado, modificado y renombrado entre en el commit, salvo borrador.txt, que no debe versionarse nunca.

Crea un repositorio de prueba y provoca deliberadamente la situación en la que se confirma una versión antigua de un fichero:

1. Crea un repositorio con un fichero app.js que contenga la línea const version = 1; y confírmalo.
2. Cambia la línea a const version = 2; y prepara el cambio.
3. Sin confirmar, cambia la línea a const version = 3;.
4. Comprueba el estado en forma corta y larga.
5. Confirma sin volver a preparar.
6. Averigua con comandos qué versión ha quedado registrada en el historial y cuál sigue en tu disco.
7. Arregla la situación para que el historial refleje la versión 3.

Te pasan un proyecto en el que git status muestra esto:

Solo src/nuevoModulo.js debe versionarse. Escribe:

1. El .gitignore que deja git status mostrando únicamente ese fichero.
2. Los comandos para verificar que funciona, incluida una comprobación explícita de que .env está siendo ignorado y por qué regla.
3. La secuencia para confirmar el .gitignore y el módulo nuevo en dos confirmaciones separadas, y una justificación de por qué separarlas.

Solución al Ejercicio 1

1. Qué entrará en el commit. Todo lo que tenga algo distinto de un espacio en la primera columna:

No entran estilos.css ( M), index.html ( D) ni borrador.txt (??), porque su primera columna está vacía o son ficheros desconocidos para Git.

2. app.js es el caso MM: hay una versión preparada y, encima, el fichero del disco es distinto de ella. Al confirmar quedará registrada la versión preparada, no la que hay en el disco. La diferencia entre ambas se quedará como cambio pendiente después del commit.

3. index.html no desaparecerá. El código D indica que el borrado está en el disco pero no preparado. La confirmación seguirá conteniendo el fichero, así que quien clone el repositorio lo recibirá. Es un error habitual: borrar con el explorador de ficheros y olvidar registrar el borrado.

4. Una confirmación por delante, según [ahead 1]: hay un commit local que el remoto todavía no tiene.

5. La secuencia:

La segunda columna está vacía en todas las líneas y borrador.txt ha desaparecido: exactamente lo pedido. La opción -u de git add es la clave —prepara modificaciones y borrados de ficheros ya rastreados, sin tocar los nuevos— y la estudiaremos en detalle en la lección siguiente.

Solución al Ejercicio 2

Pasos 1 a 3:

Paso 4 — el estado:

El mismo fichero aparece dos veces. La forma larga lo hace evidente; la corta lo condensa en MM.

Paso 5 — confirmar:

Paso 6 — qué ha quedado dónde:

Confirmado: ha entrado la versión 2, la que estaba preparada. La 3 sigue en el directorio de trabajo, todavía sin registrar. Este es el efecto exacto que produce ignorar un MM.

Paso 7 — arreglarlo:

Es la solución más segura: una confirmación nueva encima. (Existe otra alternativa, git commit --amend, que corrige la confirmación anterior en lugar de añadir una nueva; se estudia en la lección siguiente y conviene usarla solo sobre confirmaciones que aún no se han compartido, porque reescribe el historial.)

Solución al Ejercicio 3

1. El .gitignore:

2. Verificación:

Exactamente dos entradas: el propio .gitignore y el fichero que sí queremos versionar.

Para comprobar por qué se ignora un fichero concreto existe un comando específico:

La salida indica el fichero de reglas, el número de línea, el patrón que coincide y el fichero evaluado. Es la herramienta correcta para depurar un .gitignore que "no funciona": si el comando no devuelve nada, es que ninguna regla se aplica.

Y una comprobación adicional que da tranquilidad:

3. Dos confirmaciones separadas:

Por qué separarlas. Son dos cambios sin ninguna relación: uno configura qué versiona el proyecto y el otro añade funcionalidad. Separarlos tiene ventajas concretas:

• Cada confirmación puede describirse con una sola frase honesta.
• Si mañana hay que revisar por qué se ignora dist/, se encuentra una confirmación que habla solo de eso.
• Si el módulo nuevo resulta ser un error y hay que deshacerlo, se deshace sin arrastrar el .gitignore.

Es la idea de commit atómico, que desarrollamos justo en la siguiente lección.

Ya tienes el ciclo completo. Recapitulando:

• El flujo básico son tres pasos —editar, preparar, confirmar— y dos comandos, git add y git commit. El paso intermedio existe para separar el trabajo (qué he cambiado) del criterio (qué forma una unidad con sentido).
• Las tres zonas se mueven con comandos concretos: git add lleva del directorio de trabajo al área de preparación, git commit del área al repositorio, y git restore deshace en ambas direcciones.
• Un fichero atraviesa cuatro estados: sin seguimiento, sin modificar, modificado y preparado. Solo los tres últimos corresponden a ficheros rastreados, y muchos comandos actúan únicamente sobre esos.
• Un mismo fichero puede estar en dos estados a la vez (el caso MM), y si no lo detectas confirmarás una versión que no es la que tienes delante.
• git status es la brújula. En su forma larga enseña; en su forma corta (-s, -sb) informa de un vistazo, con dos columnas que separan el área de preparación del directorio de trabajo.
• .gitignore mantiene la señal limpia excluyendo lo que nunca debe versionarse, pero solo actúa sobre ficheros sin seguimiento.

Con esto ya puedes trabajar. Lo que falta es precisión: hasta ahora hemos preparado ficheros enteros con git add <fichero>, y eso no siempre es lo que quieres. ¿Y si en un mismo fichero tienes dos cambios que pertenecen a confirmaciones distintas? ¿Cómo quitas algo del área de preparación? ¿Cómo se borra o se renombra un fichero dentro de Git? ¿Y si te equivocas en el mensaje del commit que acabas de hacer?

De todo eso trata la siguiente lección, Preparando y Confirmando Cambios: git add a fondo con sus opciones -A, -u y . —una fuente clásica de confusión— y el modo interactivo por fragmentos, cómo deshacer preparaciones con git restore, git mv y git rm, y todas las variantes de git commit, incluida --amend para corregir la última confirmación.