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

38

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?

kyrisu
fuente

Respuestas:

42

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.

Rangzen
fuente
1
+1 Esa es una buena manera de lidiar con eso y puedes buscar fácilmente los cambios.
Sardathrion - Restablece a Monica el
12
EEk! ¡Te llevaste la libertad de expresión!
CaffGeek
1
¿Podría explicar alguna diferencia entre Mody Ref? A veces solo estoy haciendo pequeñas correcciones, que es algún tipo de refactorización.
yegle
2
@yegle Modse trata de agregar algo o cambiar un comportamiento, Refse trata de cambiar cosas internas que no agregan ninguna funcionalidad, agregar API, etc. Ejemplo: si tengo una add(Object)función e implemento una add(List<Object>)función, comentaré con Mod. Más tarde se quita la duplicación y utilizar directamente add(Object)en la add(List<Object>)continuación, voy a utilizar Ref.
Rangzen
14

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.

Andrey Taptunov
fuente
+1 para la corrección de errores, pero ¿qué pasa con las nuevas características? A menos que también se creen nuevas funciones en JIRA ...
Sardathrion - Reinstate Monica
3
@Sardathrion: personalmente, crearía rastreadores para la nueva funcionalidad en JIRA. Hacemos esto con Bugzilla y le da al equipo de prueba (y a todos los demás) una buena visibilidad de todo lo que se pone en una versión y minimiza las cosas que salen cuando no se han probado / revisado el código / lo que sea.
Jon Hopkins, el
@ JonHopkins: Si bien se puede usar un rastreador de errores para nuevas funciones, puede que no sea la herramienta ideal. Por supuesto, su millaje variará ^ _ ~
Sardathrion - Reinstate Monica
3
Llegué a amar tener un boleto asignado a cada confirmación (algunas entradas pueden tener múltiples confirmaciones, por supuesto): es una forma muy simple de obtener más información de fondo al inspeccionar el código más adelante. "¿Por qué hacen eso?" es mucho más fácil responder cuando tiene el comentario de confirmación y una entrada de seguimiento de problemas.
Joachim Sauer
¿No es mejor hacer un boleto en una sucursal separada?
Tamás Szelei
11

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.

barjak
fuente
Nunca he visto una razón para escribir un mensaje de confirmación largo y detallado en Git. La información detallada va en el rastreador de problemas, por lo que mis mensajes de confirmación son solo descripciones de una oración del cambio (pequeño) que hice en esa confirmación.
Marnen Laibow-Koser
9

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.

Alba
fuente
44
Muchas herramientas de error le permitirán vincular directamente a la revisión en su herramienta SCM si ingresa los detalles en el formato correcto. Del mismo modo, muchas herramientas SCM se vincularán directamente a la base de datos de errores si ingresa los detalles del error en el formato correcto. OMI, mientras hagas esto, entonces eres dorado.
Dean Harding
4

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.


fuente
0

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.

Nadie
fuente
0

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.

ryanzec
fuente
0

[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

laplasz
fuente
Su respuesta sería más fuerte si explicara por qué siente que este es un formato tan bueno. Si bien el valor de este formato puede ser evidente para usted, su valor no es tan obvio para los demás.
gracias por el comentario - sí, explicaré con más detalle pronto - Solo quería comenzar con hechos - sería una buena característica de pila que podría firmar la respuesta con WIP :)
laplasz
Para 'Work In Progress': ¿es esta una nota para ustedes mismos que volverán y enmendarán, o se comprometen a dominar con esto? Si es así, ¿por qué?
JBRWilkinson
IC del flujo de trabajo puede requerir que - por lo que empuja a dominar el cambio sin terminar sólo para integrarlo tan pronto como sea posible
laplasz