Cualquier desarrollador de cualquier nivel se ha enfrentado a tener que realizar al menos un commit en la vida. De hecho, diría que los desarrolladores tiramos un buen número de commits al día desde que comenzamos a programar. Un commit tiene una particularidad, nos pide un fragmento de texto que el propio Git se encarga en sugerirnos sea una breve descripción de nuestros cambios. En esta entrada no profundizaré sobre el debate de "la frecuencia de cada commits", pero si quiero escribir brevemente sobre la convención. Ya que podemos escribir cualquier cosa, ¿existe una forma mejor que otra?
No hay un estándar
Para empezar, respondiendo a la pregunta, cada desarrollador puede hacer el commit como quiera. El nivel de profesionalidad no se mide en eso. Lo que si es cierto es que, con el correr de los años, se ha puesto de manifiesto una convención que hoy es usada por, aproximadamente, el 20% de los repositorios en Github. Esto hace que se vuelva atractivo para cierto grupo de desarrolladores (me incluyo) ya que ayuda a entender el historial de programación de un proyecto de interés, y además permite armar herramientas afines (como la herramienta para crear changelogs automáticamente).
La Convención
Lo que más me gusta de la convención es que extremadamente sencilla de seguir, consiste en solo tres partes:
<type>(<scope>): <description>
Lo coloco en inglés porque de hecho parte de la convención es escribir los commits en dicho idioma, al tratarse de un idioma muy común en la comunidad, forma parte del respeto hacia programadores de otras partes del mundo escribir nuestros commits y comentarios en inglés (ya nos ha pasado a varios encontrar un código interesante comentado completamente en Japonés).
El type es el tipo de commit, y va un poco ligado a la frecuencia del mismo, pero por lo general se resume en solo dos: feat y fix. Un feat es una nueva característica del código y un fix un arreglo. Existen otros menos usados pero interesantes para ciertos proyectos, como docs (cuando se hace un commit que modifica la documentación), style (para commits que modifican el estilo), test (para commits que agregan testing), build (para commits donde se agrega algo relacionado a la compilación), refactor (para commits donde se refactoriza código), entre otros. Muchos de los tipos están específicados en la convención de Angular.
El scope se escribe a continuación del type entre paréntesis, es opcional (así que no se usa tanto) y sirve para agregar contexto al commit mediante una sola palabra. Por ejemplo, si en un proyecto de Angular arreglo un error con un Pipe, entonces su commit puede ser fix(pipe). Por su parte, description será un breve mensaje de descripción, en minúsculas y que no termine en punto. Se estima también escribir en infinitivo. Siguiendo el ejemplo anterior, si el fix es sobre el Pipe que da formato a las fechas y es por un error en el local de idioma, su commit puede ser el siguiente:
fix(pipe): add locale to date pipe
Con esto solo ya se tiene un commit convencial de git, aunque si se trata de un commit de consideración, se recomienda agregarle un mensaje dando más detalles del cambio, e incluso un footer (donde puede darse más información relevante como versiones y demás). Un caso reciente que se me viene a la cabeza fue la introducción de Spreadsheet desde Odoo EE hacia Odoo CE en la versión alpha de 16. Ya que sabían que la comunidad iba a estar mirando un commit tan importante, agregaron un mensaje aclarando para que se iba a utilizar a futuro.
