¿Me puede recomendar una buena plantilla de mensaje de compromiso / directrices para hacer cumplir en la empresa? [cerrado]

En Git es posible establecer y aplicar una buena plantilla de confirmación.

¿Puede recomendar (preferiblemente con argumentación) una buena plantilla / directrices de compromiso para hacer cumplir en la empresa?

yo suelo

[Abc]: Message.

Con Add, Mod (ify), Ref (actoring), Fix, Rem (ove) y Rea (dability), es fácil extraer el archivo de registro.

Ejemplo:

Add: New function to rule the world.  
Mod: Add women factor in Domination.ruleTheWorld().  
Ref: Extract empathy stuff to an abstract class.  
Fix: RUL-42 or #42 Starvation need to be initialised before Energy to avoid the nullpointer in People.  
Rem: freeSpeech is not used anymore.  
Rea: Removed old TODO and extra space in header.  

Si tengo más de una línea, las clasifico con las más importantes primero.

Usamos lo siguiente:

[Id. Del ticket en JIRA]: [Mensaje: lo que se hizo] Por ejemplo - ABC-123: Se agregó la capacidad de configurar la presentación por región.

En este caso, con la integración adecuada, podrá cambiar / eliminar / agregar archivos en su rastreador de problemas. Sin embargo, tenga en cuenta que debe evitar algo como ABC-123: Listo o ABC-123: Solucionado con filtros si es posible.

Hay una regla simple, que es una convención seguida por muchos (si no todos) SCM y la mayoría de las herramientas que funcionan con SCM:

La primera línea de un mensaje de confirmación es un breve resumen, mientras que el resto del mensaje contiene los detalles.

Por lo tanto, la mayoría de las herramientas muestran solo la primera línea y muestran el mensaje completo a pedido.

Un mal uso típico de un mensaje de confirmación es una lista con viñetas de cambios (solo se mostrará la primera viñeta). Otro mal uso es escribir un mensaje detallado muuuy largo en una sola línea.

Entonces, si hay algo que hacer cumplir, diría que es la longitud máxima de la primera línea.

Personalmente, nunca he visto una plantilla de confirmación general que valga la pena usar. El comentario debe decir de manera concisa a qué se relacionan las confirmaciones, por ejemplo, qué función / corrección de errores o una breve declaración de por qué se hicieron los cambios.

La información sobre lo que se comprometió no debe incluirse, esto puede ser determinado por el sistema scm. Más información de errores / características pertenece a donde se rastrean errores y características.

Al actualizar un informe de error después de una confirmación, encuentro que también es bueno indicar la revisión de confirmación junto con los comentarios en el informe de error. De esta manera, puede encontrar el camino desde el comentario de confirmación hasta el informe de error, y para cada comentario en el informe de error puede encontrar lo que se confirmó, pero no duplica la información al incluirla tanto en el informe de error como en el mensaje de confirmación.

Luego, al ver el historial de revisiones de un archivo, tiene buenos mensajes breves que describen el historial, pero también sabe dónde buscar más detalles, informes de errores o descripciones de tareas para obtener más detalles.

En Git es posible hacer cumplir casi cualquier cosa con los ganchos de Git . Consulte los ejemplos en .git / hooks para obtener ideas.

En cuanto al mensaje, en un caso muy general, desea incluir suficiente información sobre el problema que estaba resolviendo Y la solución en sí misma para poder encontrar e identificar este compromiso más adelante. En la mayoría de los casos, el problema se referirá a un número de error (con una integración adecuada con su sistema de seguimiento de errores). Si tiene otros sistemas con los que se integra su proceso (como el sistema de seguimiento de revisión de código), incluya también los bits apropiados:

Extracted checking foobar range from bar() into foo(min, max) to re-use
in yadda() and blah(). foo() returns true if foobar is in the
specified range and false otherwise.

BugID: 123456
ReviewedBy: mabuddy
AutomergeTo: none

PERO quieres que sea sencillo. De lo contrario, las personas encontrarán una manera de engañar al sistema y producir mensajes de confirmación inútiles.

Usamos una plantilla que contiene

• El número de identificación del error / función / corrección
• Un sí / no que describe si el código se prueba o no
• Y una sección de detalles para una breve descripción de la intención del commit

Sin embargo, los dos primeros se omiten la mayor parte del tiempo (ocasionalmente los tres), por lo que no es un gran problema.

Generalmente tengo el identificador que está en el sistema de seguimiento de tickets que uso o una descripción general de alto nivel como la primera línea. Luego tengo puntos de "viñeta" de la línea de pedido del cambio específico en la confirmación. Entonces podría de algo como:

MyVideoGameProject-123 OR Inventory System Improvements
Made inventory GUI drap and drap
Added ability to have multiple bag slots to expand inventory capacity

Este es el formato de confirmación más limpio que me gusta. Es directo y al grano. Otra razón por la que lo hago de esta manera es que si quiero crear un registro de cambios, podría tomar todos los mensajes de confirmación y analizarlos en un registro de cambios con mucha facilidad.

[ticketId] [ABC] [topicId] [WIP] Mensaje, donde:

• ticketId: identificación de un elemento en el repositorio de tareas
• ABC: agregar (función), corregir (corrección de errores), str (estructura), dep (dependencia) rem (incompatibilidad / eliminación hacia atrás), rea (legibilidad), ref (refactorización)
• topicId: puede ser un selector de trabajo para jenkins y / o nombre de sucursal y / o nombre de tema para gerrit
• WIP: trabajo en progreso o no (es decir, la integración continua puede requerir esto)
• mensaje - detalle de la modificación

Ejemplos:
[# 452567] [agregar] [elemento_menú] nuevo elemento - libro de visitas
[# 452363] [corregir] [banner_top] [WIP] 1024x300 se puede usar ahora
[# 452363] [corregir] [banner_top] 500x200 se puede usar ahora
[ # 452713] [rem] [página] anuncio medio izquierdo