Revision de Historial Git

El Problema

El historial git es la memoria institucional de un proyecto — pero la mayoria de equipos lo tratan como un basurero. Commits como “fix stuff,” “WIP,” y “final final v3” no dicen nada a futuros desarrolladores. Feature branches viven por meses, acumulando decenas de merge commits que oscurecen el trabajo real. Cuando aparece un bug en produccion y alguien ejecuta git bisect, es imposible aislar el cambio que rompio las cosas.

El Prompt

Revisa el siguiente historial git. Actua como un staff engineer evaluando las practicas de control de versiones del equipo para claridad y trazabilidad.

GIT LOG:
[pegar salida de git log --oneline --graph -30]

DIFFS RECIENTES (opcional):
[pegar diffs relevantes]

Evalua en estas dimensiones:

1. **Mensajes de Commit**
   - Los mensajes explican QUE cambio y POR QUE?
   - Hay formato consistente (conventional commits, etiquetas prefijo)?
   - Los mensajes son concisos en asunto (<72 caracteres)?
   - Los mensajes referencian numeros de issue/ticket?

2. **Granularidad de Commits**
   - Cada commit es un solo cambio logico?
   - Hay commits vacios, WIP, o "ups" fix-up?
   - Seria efectivo `git bisect` (cada commit compila y tests pasan)?

3. **Estrategia de Branches**
   - Los feature branches son de corta vida (mergeados en dias)?
   - El modelo de branching es claro (trunk-based, gitflow, GitHub flow)?
   - Los nombres de branches son descriptivos (feat/, fix/, refactor/)?

4. **Higiene de Merge**
   - Los merge commits son limpios?
   - El equipo usa rebase o squash para historial limpio?
   - Hay merge commits que accidentalmente revierten cambios previos?

5. **Datos Sensibles**
   - Se commitearon secretos, credenciales o archivos .env alguna vez?
   - Se commitearon archivos binarios grandes que deberian estar en LFS?

6. **Trazabilidad**
   - Se puede trazar un cambio de codigo a un requerimiento?
   - Los PRs estan vinculados a issues?

Para cada problema, proporciona:
- **Commit(s)**: SHA o mensaje
- **Problema**: Por que dana la capacidad del equipo para mantener el codigo
- **Severidad**: Riesgo-auditoria / Confusion / Estilo
- **Fix**: Practica corregida o limpieza retroactiva

Ejemplo de Salida

## Revision de Historial Git: 4 problemas encontrados

### Confusion: Mensajes de Commit sin Significado
Commits: "fix" (x7), "update" (x4), "WIP" (x3)
Fix: Adoptar conventional commits:
  feat(auth): agregar flujo de reset de password (#234)
  fix(cart): prevenir doble cargo en retry (#567)

### Riesgo de Auditoria: Secreto Commiteado y Eliminado
Commit: abc123 — .env con DATABASE_URL commiteado, eliminado en def456.
Problema: El secreto sigue existiendo en el historial git.
Fix: Rotar la credencial DATABASE_URL inmediatamente. Usar git-filter-repo para purgar.

Cuando Usar

Ejecutar al incorporarse a un proyecto, durante revisiones de proceso del equipo, o cuando git bisect falla para encontrar una regresion. Valioso como auditoria periodica (trimestral).

Tips Pro

• Incluir el grafo git — usar git log --oneline --graph --all -30 para mostrar estructura de branches.
• Verificar secretos retroactivamente — “Escanea este log git por commits que pudieron haber incluido secretos.”
• Establecer convenciones temprano — “Genera una seccion CONTRIBUTING.md con guias de mensajes de commit y reglas de nombres de branch.”