Cómo organizo mis commits en Git y por qué uso esta metodología

Gabriel Gómez Gómez ·

Cómo organizo mis commits en Git y por qué uso esta metodología

  • Cuando trabajo en un proyecto, no solo me interesa que el código funcione. También me interesa que el historial de cambios sea claro, ordenado y fácil de entender. Por eso utilizo una metodología para escribir mis commits basada en una estructura simple:

  • terminalBASH
    git commit -m "tipo(área): descripción del cambio"

  • Por ejemplo:

  • terminalBASH
    git commit -m "content(blog): agrega nueva nota sobre buenas prácticas en Git"

  • Esta forma de escribir commits me ayuda a identificar rápidamente qué tipo de cambio hice, en qué parte del proyecto ocurrió y cuál fue el propósito del ajuste.

  • ¿Por qué no escribo commits genéricos?

  • Antes podría parecer suficiente escribir mensajes como:

  • terminalBASH
    git commit -m "cambios"

  • o:

  • terminalBASH
    git commit -m "actualización"

  • Pero este tipo de mensajes no explica realmente qué se modificó. Cuando el proyecto crece, estos commits se vuelven difíciles de revisar porque no permiten saber si el cambio fue una corrección, una nueva funcionalidad, una mejora visual, documentación o simplemente contenido nuevo.

  • Por eso prefiero usar una metodología más clara y descriptiva.

  • Tipos de commits que utilizo

  • La idea es clasificar cada cambio según su intención. Algunos de los tipos más comunes que uso son:

    • feat: nueva funcionalidad
    • fix: corrección de errores
    • refactor: mejora interna del código
    • style: cambios visuales o de formato
    • docs: documentación
    • content: contenido nuevo o modificación de textos
    • chore: tareas de mantenimiento
    • build: cambios de compilación o configuración
    • ci: integración continua o despliegue
    • perf: mejoras de rendimiento
    • test: pruebas

  • Esta clasificación me permite leer el historial del proyecto y entender rápidamente qué pasó en cada etapa.

  • Por qué uso content para textos o notas de blog

  • Cuando agrego una nueva nota en un blog, muchas veces no estoy creando una funcionalidad nueva como tal. Lo que estoy haciendo es agregar contenido visible para el usuario.

  • Por eso, en lugar de usar siempre feat, prefiero usar:

  • terminalBASH
    git commit -m "content(blog): agrega nueva nota"

  • Este mensaje es más preciso, porque indica que el cambio corresponde a contenido dentro del blog.

  • Si la nota trata sobre un tema específico, puedo hacerlo todavía más claro:

  • terminalBASH
    git commit -m "content(blog): agrega nota sobre configuración de subdominios"

  • De esta forma, cuando revise el historial, podré saber exactamente qué contenido se agregó sin tener que abrir el commit completo.

  • Cuándo uso feat

  • Uso feat cuando realmente estoy agregando una funcionalidad nueva al sistema. Por ejemplo:

  • terminalBASH
    git commit -m "feat(blog): agrega buscador de notas"

  • En este caso sí se trata de una funcionalidad nueva, porque el usuario podrá buscar publicaciones dentro del blog.

  • Pero si solo agrego texto, una nueva entrada o actualizo contenido, prefiero usar content.

  • Cuándo uso docs

  • Uso docs cuando el cambio corresponde a documentación técnica, como instrucciones de instalación, configuración del proyecto, uso de comandos o explicación para desarrolladores.

  • Por ejemplo:

  • terminalBASH
    git commit -m "docs: agrega guía de instalación del proyecto"

  • La diferencia principal es que docs se enfoca en documentación del proyecto, mientras que content se enfoca en contenido visible o editorial, como textos de páginas, notas, artículos o publicaciones.

  • Ventajas de usar esta metodología

  • Usar esta forma de escribir commits me ayuda a mantener un historial mucho más profesional y entendible.

  • Entre las principales ventajas están:

    • Mayor claridad: cada commit explica qué se hizo.
    • Mejor organización: puedo identificar cambios por tipo y área.
    • Facilidad para revisar errores: si algo falla, puedo ubicar más rápido qué commit pudo haberlo causado.
    • Historial más limpio: evito mensajes genéricos como “cambios” o “actualización”.
    • Mejor trabajo en equipo: otras personas pueden entender el avance del proyecto sin preguntarme directamente.

  • Ejemplos prácticos

  • Si agrego una nueva nota al blog:

  • terminalBASH
    git commit -m "content(blog): agrega nueva nota"

  • Si corrijo un error en el formulario:

  • terminalBASH
    git commit -m "fix(form): corrige validación de campos obligatorios"

  • Si agrego una nueva sección al sitio:

  • terminalBASH
    git commit -m "feat(home): agrega sección de noticias"

  • Si solo ajusto estilos:

  • terminalBASH
    git commit -m "style(navbar): ajusta espaciado en versión móvil"

  • Si mejoro el código sin cambiar lo que ve el usuario:

  • terminalBASH
    git commit -m "refactor(api): simplifica manejo de respuestas"

  • Conclusión

  • Utilizo esta metodología porque me permite trabajar de forma más ordenada y profesional. Un buen commit no solo guarda cambios en Git; también documenta la evolución del proyecto.

  • Por eso, cuando agrego contenido a un blog, prefiero usar un mensaje como:

  • terminalBASH
    git commit -m "content(blog): agrega nueva nota"

  • Es claro, específico y describe correctamente el tipo de cambio realizado. De esta manera, el historial del proyecto se mantiene limpio, entendible y útil para futuras revisiones.