git commit - format?

Question

¿Cuál es el formato recomendado para usar en los mensajes de confirmación de git (COMMIT_EDITMSG), si hay alguno?

Answer 1

Varía, por supuesto, pero un formato muy común es algo como esto (tomado de http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html, que creo que resume todo muy bien):

Short (50 chars or less) summary of changes 

More detailed explanatory text, if necessary. Wrap it to about 72 
characters or so. In some contexts, the first line is treated as the 
subject of an email and the rest of the text as the body. The blank 
line separating the summary from the body is critical (unless you omit 
the body entirely); tools like rebase can get confused if you run the 
two together. 

Further paragraphs come after blank lines. 

- Bullet points are okay, too 

- Typically a hyphen or asterisk is used for the bullet, preceded by a 
    single space, with blank lines in between, but conventions vary here 

Una cosa que no aborda es algo He adoptado por mí mismo, es decir, el uso de etiquetas cortas al comienzo de la primera línea para identificar qué tipo de compromiso es. Eso podría ser etiquetas como [fix] para una corrección de errores, [new] para una nueva característica o [dev] para una confirmación que solo afecta a las partes internas. Con una política como esa, es fácil generar automáticamente un registro de cambios de las confirmaciones.

Editar: Aquí hay otro buen resumen, desde este sitio, incluso: In git, what are some good conventions to format multiple comments to a single commit

Answer 2

No recomendaría mensajes de gran tamaño. Si no puede explicar en una oración lo que está haciendo, su compromiso abarca demasiado cambio. Use git rebase -i y divida su confirmación si ya se ha comprometido. Si aún no ha confirmado los cambios, use git add -p en el escenario en partes pequeñas y luego realice commits más pequeños.

Un historial de cambios granulares como este ayudará a las fusiones y rebases posteriores. También lo ayudará a enlazar con su rastreador de problemas. Si tiene 2 o más tickets abordados, será más difícil descifrar a qué ticket se dirigió cada cambio en la confirmación.