Las Mejores Formas de Escribir Mensajes de Commit en Git: Como los Profesionales

Cuando un desarrollador retrocede en el tiempo para buscar algo en lo que trabajó hace seis meses, muchas veces no entiende por qué hizo ese compromiso en particular, y la única razón de ello es porque no siguió la forma correcta de escribir el mensaje de compromiso.

\ Existen estándares de mensajes de compromiso que los desarrolladores practican en todo el mundo, y es bueno seguir estándares populares para que cuando regreses después de un buen tiempo o alguien más mire tus mensajes de compromiso, ¡no parezcan vergonzosos!

\

\ Los equipos primero deben decidir sobre una convención de mensajes de compromiso que especifique el historial de control de versiones del producto que están construyendo.

\ Un gran mensaje de compromiso de Git debe tener un estilo adecuado, contenido y metadatos.

\ Un compromiso de Git conocido sigue esta convención:

<tipo>(<alcance>): <mensaje>

\ <tipo> puede ser uno de los siguientes:

• feat para una nueva característica.
• refactor para refactorizar código de producción, por ejemplo, renombrar una función.
• docs para cambios en la documentación.
• fix para una corrección de error para el usuario.
• perf para mejoras de rendimiento.
• style para cambios de formato, puntos y comas faltantes, etc.
• test para agregar pruebas faltantes, refactorizar pruebas.
• build para actualizar la configuración de compilación, herramientas de desarrollo u otros cambios irrelevantes para el usuario.

\ También puedes agregar tu tipo personalizado, dependiendo de los estándares que siga tu equipo. Los estándares anteriores son seguidos por el equipo de ESLint. Puedes verificar sus mensajes de compromiso aquí.

\ El alcance es opcional, y la parte del mensaje debe incluir una declaración de una sola línea, no más de 72 caracteres, para resumir para qué es el compromiso.

\ Muchos desarrolladores también usan el mensaje como línea de asunto y agregan un cuerpo también; eso es básicamente la descripción del compromiso, pero un mensaje de compromiso de una línea es preferible siempre que puedas entender el contexto (qué y por qué del compromiso). Si el compromiso exige una descripción más detallada que no se puede explicar en una sola línea, un cuerpo de compromiso siempre es necesario.

\ También puedes usar herramientas como Glitter o Commitizen para estandarizar tus mensajes de compromiso.

\ No solo esto, también podrías preguntarte si existe una herramienta que verifique tu mensaje de compromiso y muestre un error si no sigue las pautas. Commit lint es una de ellas. Ayuda a tu equipo a adherirse a una convención de compromiso.

\ Muchas veces, los expertos de la industria usan su ticket de JIRA o Click Up como mensaje de compromiso para que todo pueda ser vinculado o rastreado en cualquier momento, y la base de código siga siendo mantenible para futuros desarrolladores.

\ A algunos equipos también les gusta agregar emojis a sus mensajes de compromiso. He curado una lista de emojis y sus respectivos significados. Puedes consultarla aquí.

\ Al final, lo importante es que tu mensaje de compromiso sea significativo y no confunda a tus compañeros desarrolladores o futuros desarrolladores sobre de qué se trata un cambio en particular.

\ Si deseas aprender más sobre compromisos convencionales, compromisos semánticos o las prácticas que sigue la industria, aquí hay algunos recursos para ti:

1. Compromisos Convencionales
2. Compromisos Semánticos
3. Cómo escribir un mensaje de compromiso por CBeams

\