Commit

Analogía

Un punto de guardado en un videojuego, con una nota: "antes de abrir la puerta del dragón".

Se hace en dos pasos

git add → eliges qué cambios entran en la foto. Esa zona intermedia se llama staging (área de preparación).
git commit -m "mensaje" → disparas la foto.

Analogía del staging: hacer la maleta. Pones cosas encima de la cama (add) y, cuando está lo que quieres, la cierras (commit). Puedes quitar algo de la cama antes de cerrar.

Un buen mensaje

❌ Malo	✅ Bueno
`cambios`	`Añade horario de verano a la landing`
`fix`	`Corrige el teléfono del pie de página`
`asdf`	`Quita el formulario antiguo de contacto`

Verbo en presente, qué cambia y, si no es obvio, por qué. Tu yo de dentro de seis meses (y la IA) lo agradecerán.

Cada cuánto

Un commit = un cambio con sentido. Pequeños y frecuentes. Y una regla específica de este roadmap: commit antes de pedir algo a la IA. Así siempre tienes un punto limpio al que volver.

Datos que verás

Cada commit tiene un identificador único, el hash (a3f9c21…). git log --oneline lista el historial con hashes y mensajes.

Un paso más: qué es exactamente esa "foto"

Un commit guarda el estado de todos los archivos del proyecto, no solo de los que cambiaron, más cuatro datos: quién lo hizo, cuándo, el mensaje y cuál era el commit anterior. Ese último dato es lo que encadena las fotos y forma el historial.

Por eso los commits no se "editan": cada uno es un punto fijo en la cadena. Si te equivocaste, lo normal es hacer otro commit que lo corrige, no reescribir el pasado.

El área de preparación existe para que la foto sea limpia: has tocado cinco archivos, pero tres eran un arreglo y dos un experimento. Con git add eliges los tres, y el commit cuenta una sola historia.