git-rewrite-commits - herramienta para reescribir automáticamente mensajes de commit de Git con IA

• Herramienta que lee y entiende todo el historial de git con IA y luego lo reescribe automáticamente a un mejor formato de Conventional Commits
• Útil cuando se necesita un historial limpio, como al ordenar un proyecto antes de publicar su código abierto, en el último pulido antes de abrir un PR del equipo o al limpiar commits de proyectos personales
• Compatible tanto con OpenAI como con Ollama, y al usar un LLM local (Ollama) es posible evitar que los diff de código salgan al exterior
• Compatible con integración de Git Hooks, por lo que se puede configurar para que la IA recomiende o genere automáticamente mensajes de commit en el momento del commit
  • Hook pre-commit: vista previa de la sugerencia de la IA antes del commit
  • Hook prepare-commit-msg: aplicación automática del mensaje aprobado
  • Cada hook requiere configuración de seguridad y funciona con un esquema opt-in
• Soporte para flujos de trabajo profesionales
  • Filtro inteligente: mediante filtrado inteligente, mejora solo los mensajes problemáticos y omite los commits que ya están bien redactados
  • Creación automática de una rama de respaldo antes de todas las operaciones para permitir recuperación
  • dry-run: vista previa antes de los cambios con --dry-run, y limitación del alcance de procesamiento con --max-commits
  • Función de puntuación de calidad (quality scoring) para identificar commits que necesitan mejora
  • Reglas por equipo mediante plantillas personalizadas y COMMIT_MESSAGE.md
    • Búsqueda automática en el directorio raíz del proyecto, .git y .github
  • Con integración con pipelines de CI/CD, se puede revisar la calidad de los commits durante la validación de PR
  • Estructura de procesamiento eficiente con indicador de progreso en tiempo real y salida en color
• Licencia MIT
• Precauciones
  • Reescribir el historial de Git cambia los hashes de commit, por lo que no se recomienda en ramas compartidas
  • Se recomienda usarlo en proyectos personales o durante la etapa de ordenamiento antes de publicar código abierto
  • No aplicarlo a ramas main/master sin acuerdo del equipo