Commits en Git: snapshots, mensajes y trazabilidad profesional

Qué es un commit: un snapshot con identidad

En Git, un commit es una “foto” (snapshot) del estado del proyecto en un momento concreto. No es solo una lista de cambios: Git guarda una referencia al contenido exacto de los archivos versionados en ese punto. Cada commit tiene un identificador (hash) y metadatos (autor, fecha y mensaje), lo que permite trazabilidad: saber qué se cambió, cuándo, por quién y por qué.

• Working tree: tus archivos tal como están en tu carpeta.
• Staging area (index): selección de cambios que entrarán en el próximo commit.
• Commit: snapshot creado a partir de lo que está en staging.

Idea clave: solo lo que está en staging entra al commit. Esto habilita commits limpios y revisables.

Preparar cambios de forma selectiva (stage parcial)

Cuando editas varios archivos o haces cambios distintos en el mismo archivo, conviene preparar (stage) solo lo que corresponde a un commit específico. Esto evita commits “mezclados” y mejora la revisión.

Paso a paso: staging selectivo con git add -p

Supón que modificaste un archivo con dos cambios distintos: uno funcional y otro de formato. Quieres separarlos.

1. Revisa qué cambió antes de preparar nada:

   Continúa en nuestra aplicación.

   • Escuche el audio con la pantalla apagada.
   • Obtenga un certificado al finalizar.
   • ¡Más de 5000 cursos para que explores!

   O continúa leyendo más abajo...

   

   Descargar la aplicación

   git diff

2. Entra al modo interactivo por “hunks” (bloques de cambios):

   git add -p

   Git te mostrará un bloque y opciones típicas:

   • y: añade este bloque a staging
   • n: no lo añadas
   • s: divide el bloque en partes más pequeñas (si es posible)
   • e: edita manualmente el bloque (avanzado)
   • q: salir

3. Comprueba qué quedó en staging vs. qué sigue sin preparar:

   git diff --staged

   git diff

4. Cuando staging contenga solo lo que quieres confirmar, crea el commit:

   git commit -m "feat: valida email en registro"

Staging selectivo por archivo

Si el cambio está bien separado por archivos, puedes preparar por archivo:

git add ruta/al/archivo.js

Y repetir para cada archivo que pertenezca al mismo commit.

Mensajes de commit útiles: asunto, cuerpo y contexto

Un buen mensaje permite entender el “por qué” sin abrir el código. Piensa en el commit como una unidad de comunicación para tu yo del futuro y para tu equipo.

Estructura recomendada

• Asunto (subject): breve, específico, describe el cambio principal.
• Cuerpo (body): explica contexto, motivación, decisiones, trade-offs.
• Referencias: IDs de issue/ticket/PR si aplica (por ejemplo, #123).

Plantilla práctica

<tipo>: <resumen en presente>

Contexto:
- ¿Qué problema había?
- ¿Qué comportamiento se esperaba?

Cambio:
- ¿Qué se hizo? (alto nivel)
- ¿Qué NO se hizo y por qué?

Impacto:
- Riesgos / compatibilidad / migraciones
- Cómo probar

Refs: #123

Ejemplos de buenos asuntos

• fix: evita NPE al guardar perfil sin avatar
• feat: añade filtro por fecha en listado de pedidos
• refactor: extrae validador de contraseña a módulo
• test: cubre caso de carrito vacío

Cómo escribir el mensaje con editor (recomendado)

Para incluir cuerpo con comodidad:

git commit

Se abrirá tu editor para escribir asunto y cuerpo. Alternativa rápida (dos -m):

git commit -m "fix: corrige cálculo de impuestos" -m "El redondeo fallaba en montos con 3 decimales. Se aplica redondeo bancario y se añaden pruebas. Refs: #418"

Cómo dividir el trabajo en commits pequeños y revisables

Un commit ideal es coherente: contiene un solo propósito. Esto facilita revisar, revertir y entender el historial.

Criterios prácticos para partir en commits

Regla de revisión

Antes de confirmar, pregúntate: “Si alguien revisa este commit, ¿puede entenderlo y aprobarlo sin leer otros commits?” Si la respuesta es no, probablemente está mezclado.

Inspeccionar el historial: git log con formatos útiles

El historial es una herramienta de diagnóstico. Aprender a leerlo bien te ahorra tiempo cuando buscas el origen de un bug o cuándo se introdujo un cambio.

Log compacto (una línea por commit)

git log --oneline

Log con gráfico de ramas

git log --oneline --graph --decorate --all

Útil para entender merges y el flujo de trabajo.

Log con parches (ver el contenido de cambios)

git log -p

Para limitar a un archivo:

git log -p -- ruta/al/archivo.js

Log con filtros por autor, fecha y mensaje

git log --author="Ana"

git log --since="2026-01-01" --until="2026-01-31"

git log --grep="impuestos"

Log con formato personalizado (trazabilidad)

git log --pretty=format:"%h %ad %an %s" --date=short

Campos comunes:

• %h: hash corto
• %ad: fecha del autor
• %an: autor
• %s: asunto

Identificar qué cambió: git diff y git show

git diff: comparar estados

• Ver cambios no preparados (working tree vs. staging):

  git diff

• Ver cambios preparados (staging vs. último commit):

  git diff --staged

• Comparar dos commits (o ramas):

  git diff COMMIT1 COMMIT2

• Comparar un commit con tu estado actual:

  git diff COMMIT

git show: ver un commit específico

Muestra metadatos + diff del commit:

git show COMMIT

Ejemplo con hash corto del log:

git log --oneline -5
git show a1b2c3d

Ver solo nombres de archivos cambiados:

git show --name-only COMMIT

Ver un resumen (líneas añadidas/eliminadas):

git show --stat COMMIT

Hábitos profesionales para evitar errores al commitear

No commitear binarios innecesarios

Evita confirmar archivos generados o pesados (por ejemplo: builds, dependencias descargadas, ejecutables, caches). Esto hace el repositorio lento y el historial ruidoso.

• Revisa qué estás a punto de incluir:

  git status

• Si ves archivos generados, exclúyelos con .gitignore (si ya existe en tu proyecto, edítalo):

  # ejemplos comunes
  node_modules/
  dist/
  *.log
  .DS_Store

Si un binario ya fue agregado por error, no basta con ignorarlo: hay que quitarlo del tracking (sin borrarlo localmente):

git rm --cached ruta/al/archivo.bin

No mezclar refactors con cambios funcionales

Un refactor cambia estructura sin cambiar comportamiento. Si lo mezclas con una nueva funcionalidad, la revisión se vuelve difícil y revertir se vuelve riesgoso.

• Haz primero un commit de refactor (idealmente con pruebas pasando).
• Luego un commit con el cambio funcional.
• Usa staging parcial para separar si ya mezclaste cambios en el mismo archivo.

Validar antes de confirmar

Antes de crear el commit, valida que el snapshot sea correcto.

1. Revisa el estado:

   git status

2. Revisa exactamente lo que va a entrar:

   git diff --staged

3. Ejecuta verificaciones del proyecto (ejemplos típicos):

   # pruebas
   npm test
   
   # lint
   npm run lint
   
   # build
   npm run build

4. Confirma con un mensaje claro (asunto + cuerpo si hace falta):

   git commit

Mini flujo recomendado (checklist) para cada commit

• 1) git diff para entender lo que cambió.
• 2) git add -p para preparar solo lo que corresponde.
• 3) git diff --staged para revisar el snapshot.
• 4) Ejecutar pruebas/lint/build según el proyecto.
• 5) git commit con asunto claro y cuerpo con contexto y referencias.
• 6) git log --oneline -5 para confirmar que el historial quedó legible.