En la lección anterior recorrimos el ciclo completo —editar, preparar, confirmar— y vimos cómo git status nos guía en cada paso. Pero usamos git add y git commit en su forma más elemental: preparar ficheros enteros y confirmar con un mensaje corto.

En la práctica eso se queda corto enseguida. Una tarde de trabajo real no produce cambios ordenados: produce un fichero con dos arreglos que no tienen nada que ver entre sí, un fichero de configuración que nunca debió versionarse, otro que hay que renombrar y un mensaje de confirmación con una errata. Git tiene una respuesta precisa para cada una de esas situaciones, y dominarlas es la diferencia entre un historial que se puede leer y uno que solo se puede sufrir.

Esta lección es la más densa del módulo. Vamos a ver git add a fondo —incluida la diferencia entre -A, -u y ., que confunde a casi todo el mundo— el modo interactivo por fragmentos, cómo deshacer una preparación, cómo mover y borrar ficheros dentro de Git, y todas las variantes útiles de git commit, incluida --amend. Cerraremos con el concepto que da sentido a todo: el commit atómico.

1. git add: las formas de indicar qué preparar
2. -A frente a -u frente a .: la tabla que resuelve la duda
3. Preparación por fragmentos con git add -p
4. Quitar del área de preparación: git restore --staged
5. Descartar cambios del directorio de trabajo: git restore
6. Mover y renombrar con git mv
7. Borrar con git rm (y el caso especial --cached)
8. git commit: todas las formas de confirmar
9. --amend: corregir la última confirmación
10. El commit atómico

git add copia el contenido actual de uno o varios ficheros al área de preparación. Acepta muchas formas de decirle sobre qué actuar:

Cuando escribes git add *.css sin comillas, quien expande el asterisco es tu intérprete de órdenes, no Git. El resultado es que solo se expanden los ficheros del directorio actual, y si no hay ninguno el comando falla.

Con comillas, el patrón llega intacto a Git, que lo aplica de forma recursiva sobre todo el repositorio:

Es una diferencia sutil con consecuencias reales. La recomendación: usa comillas cuando quieras el comportamiento de Git y sé consciente de cuál estás pidiendo.

Un malentendido frecuente es pensar que git add sirve solo para "añadir". En realidad su función es sincronizar el área de preparación con el directorio de trabajo para las rutas indicadas. Eso incluye:

• Ficheros nuevos → se empiezan a rastrear.
• Ficheros modificados → se actualiza su versión preparada.
• Ficheros borrados del disco → se prepara el borrado.

Este último caso sorprende:

Sí: git add sobre un fichero que ya no existe registra su desaparición. Tiene sentido si piensas en add como "toma nota del estado actual de esta ruta".

Dos opciones muy útiles antes de un add amplio:

En un repositorio grande o desconocido, git add -n . cuesta un segundo y evita disgustos.

Esta es, con diferencia, la confusión más extendida sobre git add. Las tres formas se parecen y hacen cosas distintas. La diferencia se explica con dos ejes: qué tipos de cambio incluyen y sobre qué parte del repositorio actúan.

Dos conclusiones se leen directamente de la tabla:

• -u es el único que no incluye ficheros nuevos. Actúa exclusivamente sobre ficheros que Git ya rastrea. Es la opción correcta cuando quieres registrar todo tu trabajo sobre ficheros conocidos sin arriesgarte a añadir un fichero nuevo por accidente.
• . y -A hacen lo mismo salvo por el alcance. La diferencia solo se nota si no estás en la raíz del repositorio.

Preparemos el escenario en el repositorio de Ana:

Caso A — git add . desde la raíz:

Todo entra: nuevos, modificados y borrados.

Caso B — git add . desde un subdirectorio:

Aquí está la trampa. Solo se ha preparado src/utilidades.js, porque . significa "el directorio actual". Los cambios de la raíz siguen sin preparar. Alguien que confirmara ahora, convencido de haber añadido todo, dejaría fuera tres cambios.

Caso C — git add -A desde el mismo subdirectorio:

-A ignora dónde estás y actúa sobre todo el repositorio. Es el comportamiento que la mayoría de la gente cree estar pidiendo cuando escribe git add ..

Caso D — git add -u:

Solo se han preparado los cambios de ficheros ya rastreados: la modificación de estilos.css y el borrado de README.md. Los dos ficheros nuevos siguen sin seguimiento. Este es el comportamiento que quieres cuando estás trabajando en medio de una carpeta llena de ficheros generados y no te fías de un add masivo.

Nota histórica. Antes de Git 2.0, git add . no preparaba los borrados, y esa asimetría causaba muchísimos problemas. Desde Git 2.0 el comportamiento es el descrito en la tabla. Si lees documentación antigua que dice lo contrario, está desactualizada.

• git add <ruta> cuando sabes exactamente qué quieres. Es la opción por defecto de quien cuida su historial.
• git add -u para registrar todo tu trabajo sobre ficheros conocidos, sin sorpresas.
• git add -A cuando de verdad quieres todo y tienes un .gitignore en el que confías.
• git add . solo si estás en la raíz y sabes que estás en la raíz.

Y en cualquier caso: git status antes de confirmar.

Llega el martes siguiente. Ana quiere implementar el marcado de tareas como completadas, pero mientras está en ello ve un color feo en estilos.css y lo corrige de paso. Al terminar, app.js contiene dos cambios sin relación: la funcionalidad nueva y una corrección menor de un mensaje de consola que también arregló al vuelo.

Preparar app.js entero mezclaría las dos cosas en la misma confirmación. La solución es el modo por fragmentos:

Git recorre el fichero mostrando los cambios en trozos (hunks) y pregunta qué hacer con cada uno:

Las respuestas posibles son muchas, pero en la práctica se usan cinco:

Veamos la sesión de Ana completa. Primer fragmento: la llamada al contador, que forma parte de la funcionalidad nueva.

Segundo fragmento: la función de marcado.

Tercer fragmento: la corrección del mensaje de consola, que no pertenece a esta confirmación.

Resultado:

app.js sale como MM: una parte preparada (la funcionalidad) y otra pendiente (el mensaje). Ahora Ana puede confirmar solo lo primero:

Y después, en una confirmación aparte, lo demás:

Dos confirmaciones limpias donde había un revoltijo.

Si dos cambios independientes caen dentro del mismo fragmento porque están cerca, s lo parte:

Git solo puede dividir cuando hay al menos una línea de contexto sin cambios entre los dos bloques. Si los cambios son literalmente contiguos, s no estará disponible y habrá que usar e.

Es la opción más potente y la que más asusta. Git abre el fragmento en tu editor (el que configuraste en Configuración Inicial) con instrucciones al final:

Las dos reglas que necesitas:

• Para no preparar una línea añadida (+), bórrala del fragmento.
• Para no preparar una línea eliminada (-), cámbiale el - por un espacio.

Nunca borres una línea que empiece por - ni añadas líneas nuevas: el parche dejaría de aplicar y Git protestará (aunque te dará la oportunidad de reintentarlo).

Comandos relacionados. -p funciona también con otros comandos: git restore -p, git stash -p, git checkout -p. Y git add -i abre un menú interactivo completo, del que -p es solo una opción. En la práctica, -p cubre el 95 % de los casos.

Preparaste algo que no querías. La operación inversa es:

Ejemplo. Ana prepara todo por costumbre y se da cuenta de que BORRADOR.md no debía entrar:

BORRADOR.md ha vuelto a ser un fichero sin seguimiento. Su contenido en el disco no se ha tocado: --staged actúa solo sobre el área de preparación.

Verás muchísima documentación —y muchos compañeros— usando esto:

Hace exactamente lo mismo. La diferencia es de diseño: git reset es un comando con tres modos y varios significados, y git checkout también estaba sobrecargado. Para resolverlo, Git 2.23 (2019) introdujo dos comandos con un propósito claro cada uno:

Las formas antiguas siguen funcionando y las verás por todas partes. Usa las modernas en tu trabajo y reconoce las antiguas cuando las leas. El uso de git reset para mover el HEAD y reescribir el historial es otro asunto, y se trata en Deshaciendo Cambios.

Sin --staged, git restore hace algo bastante más serio: sobrescribe el fichero del disco con la versión de referencia, descartando tus cambios.

Ana experimenta con un diseño en estilos.css, no le gusta nada y quiere volver atrás:

El fichero ha vuelto a como estaba. Los cambios se han perdido de forma irrecuperable: no estaban en ninguna confirmación ni en el área de preparación, así que Git no tiene copia de ellos. Este es uno de los pocos comandos de Git que destruye trabajo sin red de seguridad.

Aviso serio. Antes de un git restore, pregúntate si de verdad quieres tirar ese trabajo. Si dudas, hay alternativas que lo guardan: git stash (lección 05-04) o simplemente confirmarlo y decidir después.

Cuando un fichero está en estado MM —preparado y modificado después— hay que tener claro qué descarta cada variante:

Fíjate en la segunda fila: git restore f a secas restaura desde el área de preparación, no desde el último commit. Si habías preparado una versión intermedia, es a esa a la que vuelves.

Opciones útiles:

Esta última no es un "deshacer": modifica tu directorio de trabajo con contenido antiguo, que después puedes preparar y confirmar normalmente. Es una forma sencilla de recuperar el estado de un fichero concreto sin tocar el resto del proyecto.

Ana ha creado un fichero notas-version.md y quiere llamarlo CAMBIOS.md. Podría hacerlo con el explorador de ficheros, pero entonces Git vería un fichero borrado y otro nuevo. Lo correcto es:

El código R indica un renombrado, y el cambio ya está preparado: git mv prepara el resultado automáticamente.

Este comando no es magia. Es exactamente equivalente a tres órdenes:

De hecho, si hubieras usado mv a secas, Git detectaría el renombrado igualmente al preparar ambos cambios:

Esto conecta con algo fundamental del modelo de datos que vimos en 01-04: Git no almacena renombrados. Un blob guarda contenido, y el nombre vive en el tree. Lo que Git hace es detectar renombrados a posteriori, comparando el contenido de los ficheros borrados y añadidos. Si el contenido es idéntico, la detección es infalible; si cambiaste mucho el fichero al moverlo, quizá no lo detecte y lo muestre como un borrado más un fichero nuevo.

Y el caso incómodo: cambiar solo mayúsculas y minúsculas en macOS o Windows, donde el sistema de ficheros no distingue entre Leeme.md y LEEME.md. Como Bruno trabaja en macOS, le pasará:

La solución es el paso intermedio:

O usar -f, que en las versiones recientes de Git resuelve este caso concreto.

Para eliminar un fichero del proyecto:

Hace dos cosas a la vez: borra el fichero del disco y prepara el borrado. Equivale a rm antiguo.js && git add antiguo.js.

Si Git detecta que el fichero tiene cambios sin confirmar, se niega:

Es una protección deliberada: te avisa de que estás a punto de perder trabajo. Si estás seguro, -f.

Esta variante quita el fichero del control de versiones pero lo deja en el disco. Es la respuesta a un problema muy frecuente: un fichero que nunca debió versionarse y que ya está rastreado.

Recuerda del apartado 6 de la lección anterior: .gitignore solo actúa sobre ficheros sin seguimiento. Si config.local.json ya está en el historial, añadirlo al .gitignore no hace nada. La secuencia correcta es:

Para un directorio entero hace falta -r (recursivo):

Un truco muy útil cuando has arreglado el .gitignore y quieres que se aplique a todo lo ya rastreado:

Advertencia importante. git rm --cached deja de rastrear un fichero desde ahora, pero no lo borra del historial. Todas las confirmaciones anteriores lo siguen conteniendo, y cualquiera con acceso al repositorio puede recuperarlo. Si el fichero contenía credenciales, esto no las protege: hay que rotarlas y, si es imprescindible, reescribir el historial. Lo trataremos en Mejores Prácticas de Seguridad.

Con el área de preparación lista, toca registrar. La forma que ya conoces:

Y estas son las variantes que merece la pena conocer.

Git abre tu editor con una plantilla:

Escribes arriba, guardas y cierras. Si guardas sin escribir nada, el commit se cancela. Las líneas que empiezan por # se descartan.

Esta forma tiene dos ventajas sobre -m: te muestra qué vas a confirmar mientras escribes el mensaje (una última oportunidad de detectar un error), y facilita escribir mensajes de varias líneas.

Un mensaje de confirmación tiene dos partes: una primera línea de resumen y, opcionalmente, un cuerpo separado por una línea en blanco.

Desde el editor es natural. Desde la línea de órdenes, hay dos formas:

El resultado es idéntico. Muchos comandos —git log --oneline, la lista de confirmaciones de las plataformas web— muestran solo la primera línea, así que esa línea debe funcionar por sí sola.

Prepara automáticamente todos los ficheros rastreados que estén modificados o borrados, y confirma.

Su riesgo es que se salta el área de preparación, es decir, se salta la decisión de qué entra. Con -a confirmas todo lo que hayas tocado, incluidos:

• El console.log de depuración que dejaste en app.js.
• El ajuste de tres líneas en un fichero que no tiene nada que ver con lo que estás confirmando.
• El cambio que ibas a revisar mejor antes de registrarlo.

Además, no incluye ficheros sin seguimiento, lo que produce el error contrario: crees haber confirmado todo y el fichero nuevo se queda fuera, el proyecto no compila en la máquina de tu compañero y nadie entiende por qué.

Úsalo cuando estés seguro de que todo lo modificado pertenece a la misma confirmación, y aun así mira git status antes. Como práctica por defecto, no lo recomiendo.

git commit -v merece un comentario aparte: añade al pie de la plantilla el diff completo de lo preparado. Es la mejor forma de revisar tu propio trabajo justo antes de registrarlo, y muchos desarrolladores lo activan siempre:

Ana confirma y, un segundo después, ve la errata en el mensaje:

Solución:

Corregido. Fíjate en que el hash ha cambiado: era 9d1e4b7 y ahora es 5c2e8b4.

--amend sirve para tres cosas:

El segundo caso es el más útil en el día a día: acabas de confirmar y descubres que faltaba un fichero. En lugar de crear una confirmación "Añadir el fichero que faltaba", lo incorporas al commit anterior y el historial queda limpio.

Esto es lo que hay que entender bien, y conecta directamente con El Modelo de Datos de Git.

--amend no modifica la confirmación existente. No puede: los objetos de Git son inmutables, y su identificador es el hash de su contenido. Lo que hace es:

1. Crear un commit nuevo con el mismo padre que el anterior y el contenido/mensaje corregidos.
2. Mover la rama actual a ese commit nuevo.
3. Dejar el commit antiguo huérfano, sin nada que apunte a él.

De ahí la regla de oro:

Nunca hagas --amend sobre una confirmación que ya has compartido.

Si la confirmación 9d1e4b7 ya estaba en el servidor y Bruno la había descargado, al reescribirla tu historial y el suyo divergen: él tiene un commit que tú ya no tienes, y tu commit nuevo le resulta desconocido. Arreglarlo requiere trabajo y coordinación. Mientras la confirmación esté solo en tu máquina, --amend es seguro y muy recomendable.

La regla general —reescribe libremente lo local, nunca lo compartido— vale también para el rebase (módulo 5) y para todas las técnicas de limpieza de historial (08-02).

Todo lo anterior existe para una cosa: poder crear confirmaciones atómicas.

Un commit atómico es aquel que contiene un cambio completo y solo uno. Dos condiciones simultáneas:

• Completo: incluye todo lo necesario para que ese cambio funcione. Si añades una función y su estilo, ambos van juntos; una confirmación que deja el proyecto roto no es atómica.
• Único: no incluye nada que no pertenezca a ese cambio. Ni el arreglo de ortografía de paso, ni el console.log de depuración.

Aquí va la única regla que necesitas por ahora, y que además funciona como test de atomicidad:

Si al describir tu confirmación necesitas la palabra "y", probablemente deberían ser dos confirmaciones.

Aplicado al caso de Ana: "Marcar tareas como completadas y corregir el mensaje de consola y ajustar el color". Tres "y" implícitos, tres confirmaciones. Por eso usó git add -p.

Los beneficios se cobran meses después, cuando algo falla y hay que averiguar por qué. Herramientas como Git Bisect y Git Blame dependen por completo de esta disciplina.

Un commit atómico necesita un mensaje que lo describa. Por ahora, tres normas suficientes:

1. La primera línea, corta (unos 50 caracteres) y descriptiva por sí sola.
2. En imperativo o infinitivo, describiendo lo que hace la confirmación: "Añadir el contador de tareas", no "Añadido el contador" ni "cambios".
3. El qué en la primera línea, el porqué en el cuerpo si hace falta explicarlo.

Las convenciones completas —Conventional Commits, longitudes, cuerpo, pies, referencias a incidencias— se tratan en Escribiendo Buenos Mensajes de Confirmación. Con estas tres normas ya escribirás mejores mensajes que la media.

• Usar git add . desde un subdirectorio creyendo que añade todo. Solo añade desde ahí hacia abajo. Si quieres todo el repositorio, es git add -A.
• Esperar que -u incluya ficheros nuevos. No lo hace, por diseño. Es su ventaja, no su defecto.
• Confiar en git commit -a. Confirma todo lo modificado sin filtro y deja fuera lo nuevo. Es la receta de los commits revueltos y de los ficheros olvidados.
• git restore <fichero> a la ligera. Destruye tus cambios sin copia de seguridad. Es de los poquísimos comandos de Git sin red. Si dudas, git stash.
• Confundir git restore --staged con git restore. El primero quita del área de preparación y no toca el disco; el segundo sobrescribe el disco. La diferencia es un cambio deshecho frente a un cambio perdido.
• Creer que git rm --cached borra el fichero del historial. No lo borra: sigue en todas las confirmaciones anteriores. Para secretos, esto no basta.
• Hacer --amend sobre una confirmación ya compartida. Reescribe el historial y provoca divergencia con tus compañeros. Solo sobre lo que aún está en tu máquina.
• Confirmar el trabajo de tres días en un solo commit. Nadie puede revisarlo, deshacerlo ni entenderlo. Confirma pronto y a menudo.
• Consejo: activa git config --global commit.verbose true. Ver el diff mientras escribes el mensaje detecta muchísimos errores antes de que entren en el historial.
• Consejo: si git add -p te resulta lento al principio, insiste una semana. Es el hábito que más mejora la calidad de un historial, y acaba siendo automático.
• Consejo: cuando dudes de qué vas a confirmar, git diff --staged te lo enseña exactamente. Es el tema de la siguiente lección.

Monta este escenario:

Sitúate dentro de componentes/ y, ejecutando git reset entre pruebas para volver al punto de partida, determina qué prepara exactamente cada uno de estos comandos. Anota la salida de git status -s en cada caso y explica el porqué:

1. git add .
2. git add -A
3. git add -u
4. git add ..

En el repositorio de gestor-tareas (o en uno de prueba con un app.js similar), realiza estos dos cambios a la vez en app.js:

• Cambio A (funcionalidad): añade una función borrarTarea(id) que elimine una tarea del array y repinte la lista.
• Cambio B (mantenimiento): corrige un comentario mal escrito en la cabecera del fichero.

Después:

1. Usa git add -p para preparar solo el cambio A.
2. Demuestra con git status -s que el fichero está en estado MM.
3. Confirma el cambio A con el mensaje "Añadir borrado de tareas al listado".
4. Confirma el cambio B en una segunda confirmación.
5. Comprueba con git log --oneline que hay dos confirmaciones y con git show --stat que cada una toca lo que debe.

Un compañero te pasa un repositorio en este estado, justo después de haber confirmado:

La confirmación no se ha compartido con nadie todavía. Resuelve:

1. ¿Cuáles son los tres problemas de esta confirmación?
2. Escribe la secuencia de comandos que deja de versionar .env y node_modules/, los añade al .gitignore y conserva ambos ficheros en el disco.
3. Corrige el mensaje de la confirmación por uno descriptivo, sin crear una confirmación adicional.
4. ¿Qué habría cambiado en tu respuesta si la confirmación ya se hubiera compartido? ¿Y qué medida adicional habría que tomar por el hecho de que .env haya estado versionado?

Solución al Ejercicio 1

Estado de partida (visto desde la raíz):

1. git add . desde componentes/:

Prepara todo (nuevos, modificados y borrados) pero solo desde el directorio actual hacia abajo. Los cambios de la raíz quedan fuera.

2. git add -A:

Prepara todo el repositorio, ignorando por completo dónde estás. Las cuatro entradas tienen la primera columna ocupada.

3. git add -u:

Actúa sobre todo el repositorio, pero solo sobre ficheros rastreados: la modificación de boton.js y el borrado de raiz.txt. Los dos ficheros nuevos siguen sin seguimiento.

4. git add ..:

Mismo resultado que -A, pero por otra razón: .. es la raíz del repositorio, así que "desde ahí hacia abajo" es todo. Confirma que la diferencia entre . y -A es exclusivamente el punto de partida del recorrido.

Resumen:

Solución al Ejercicio 2

Los dos cambios en app.js. Cabecera (cambio B):

Y la función nueva (cambio A):

1. Preparar solo el cambio A:

El primer fragmento que muestra Git es el de la cabecera (está más arriba en el fichero):

Respondemos n: no pertenece a esta confirmación. El segundo es la función:

2. Comprobar el estado MM:

Primera columna M: hay una versión preparada (con la función nueva, sin la corrección del comentario). Segunda columna M: el disco difiere de ella.

Se puede verificar con más precisión:

Nueve líneas preparadas (la función) y una línea pendiente (el comentario). Exactamente la separación buscada.

3 y 4. Las dos confirmaciones:

5. Verificación:

Dos confirmaciones atómicas sobre el mismo fichero. Sin git add -p esto solo se conseguiría deshaciendo un cambio a mano, confirmando y volviéndolo a escribir.

Solución al Ejercicio 3

1. Los tres problemas:

1. .env está versionado. Contiene credenciales; ahora están en el historial y las verá cualquiera con acceso al repositorio.
2. node_modules/ está versionado. Son dependencias reinstalables: hinchan el repositorio, ensucian los diffs y no aportan nada.
3. El mensaje "arreglos varios" no dice nada. Y, de fondo, la confirmación no es atómica: mezcla lógica (app.js), estilos (estilos.css) y documentación (README.md) con ficheros que no debían estar.

2. Dejar de versionar .env y node_modules/:

--cached es la clave: los ficheros siguen en el disco, solo dejan de rastrearse.

Comprobación de que los ficheros siguen ahí:

3. Corregir el mensaje sin crear una confirmación nueva.

Como los cambios del punto 2 están preparados y la confirmación no se ha compartido, se pueden incorporar a la misma confirmación con --amend, arreglando de paso el mensaje:

.env y node_modules/ han desaparecido de la confirmación, y el mensaje ya describe algo. El hash ha cambiado (7f3c9a2 → 3b9e7d1) porque, como sabemos, --amend crea una confirmación nueva.

Nota crítica: este --amend funciona limpiamente porque 7f3c9a2 era la única confirmación que contenía .env. Si el fichero llevara veinte confirmaciones en el historial, --amend solo lo sacaría de la última y seguiría estando en las diecinueve anteriores.

Sobre el mensaje: sigue teniendo una "y", así que lo verdaderamente correcto habría sido separar la confirmación en dos (funcionalidad y estilos). Con git reset y un par de git add -p se podría hacer, pero eso ya entra en el terreno de Manteniendo un Historial Limpio.

4. Si la confirmación ya se hubiera compartido.

Cambiarían dos cosas:

• Nada de --amend. Reescribir una confirmación que otros ya tienen provoca divergencia entre historiales. La solución correcta sería una confirmación nueva encima:

El mensaje malo del commit anterior se queda ahí. Es el precio de haber publicado: el historial compartido es inmutable en la práctica.

• Y, sobre todo, hay que rotar las credenciales. Este es el punto que no se puede pasar por alto: .env estuvo en el historial y, si ese historial se compartió, las claves se consideran comprometidas. Sacarlo del seguimiento no las protege; cualquiera que haya clonado el repositorio las tiene en su disco, y git show 7f3c9a2:.env las muestra. La única respuesta válida es invalidar esas credenciales y generar unas nuevas. Limpiar el historial (con git filter-repo o similar) es un paso complementario, nunca un sustituto. Lo veremos en Mejores Prácticas de Seguridad.

Esta lección te ha dado el control fino sobre qué entra en el historial y cómo. Recapitulando:

• git add sincroniza rutas con el área de preparación, y eso incluye ficheros nuevos, modificados y borrados.
• -A, -u y . se diferencian en dos ejes: -u es el único que excluye ficheros nuevos, y . es el único limitado al directorio actual. -A es "todo, en todas partes".
• git add -p prepara por fragmentos y es la herramienta que permite separar dos cambios mezclados en un mismo fichero. Es el hábito que más mejora un historial.
• git restore --staged quita del área de preparación sin tocar el disco; git restore sobrescribe el disco y destruye tus cambios sin red de seguridad. Sus equivalentes antiguos son git reset HEAD y git checkout --.
• git mv y git rm hacen la operación del sistema de ficheros y la preparan de una vez. git rm --cached deja de rastrear conservando el fichero, y es la pieza que falta cuando un .gitignore "no funciona".
• git commit admite mensaje en línea o en el editor, mensajes multilínea y la opción -a, que es cómoda y arriesgada: confirma todo lo modificado y deja fuera lo nuevo.
• --amend corrige la última confirmación creando una nueva y descartando la anterior. Es seguro y muy útil mientras esa confirmación no se haya compartido.
• El commit atómico —un cambio completo y solo uno— es el objetivo de todo lo anterior. La regla mínima: si necesitas "y" para describirlo, sepáralo.

Ana ya sabe elegir con precisión qué confirma. Pero hay una pieza que hemos usado sin explicar: en el modo -p, Git le mostraba los cambios en un formato con líneas + y -, cabeceras @@ y fragmentos. Ese formato aparece por todas partes en Git y saber leerlo es imprescindible.

En la siguiente lección, Inspeccionando Cambios con git diff, aprenderemos a ver exactamente qué ha cambiado antes de confirmar: la diferencia entre git diff, git diff --staged y git diff HEAD según qué zonas comparan, cómo leer el formato unified diff línea a línea, cómo comparar dos confirmaciones concretas o un fichero suelto, y las opciones que hacen la salida legible en los casos difíciles.