Estrategia para la extracción de los mensajes de la mayoría de las confirmaciones útiles para changelog

Question

Las necesidades para esta pregunta es

• tienen una lista de cambios para los gerentes/clientes que:
  • se incluyen las "Permitir que los usuarios tienen direcciones adicionales"
  • no incluye "se ha corregido el error en el que se sobreescriben direcciones debido a X"
• evitar tener que mirar a través de registro completo la historia para encontrar las confirmaciones más importantes (más a menudo hacia atrás incompatibles) para cada construir
• que sea lo más fácil de leer como el registro de cambios típico juego ("problemas de equilibrio fijo: X" y "Controlador de gráficos Y dictado la juego poco a poco ")

Hoy en día, estamos usando banderas en los mensajes de confirmación como

Add|Ref|Rem|Fix: <msg> para la habitual cometer.

Como tal, mi primer intento en este habría que añadir otro nivel de esas banderas, por ejemplo

CL-Add: feature X (CL = cambios) y luego analizar todos los mensajes de confirmación para ^CL-(Add|Ref|Rem|Fix) añadir a la lista de cambios.

Pero entonces, ¿cómo abordaría la posibilidad de tener mensajes de compromiso escritos solo para registros de cambios (es decir, un nivel demasiado alto); o mensajes múltiples sobre el mismo problema de registro de cambios. Quizás los mensajes de registro de cambios deberían extraerse más bien cuando se fusionan las ramas de características? ¿Hay características de SCM: s (por ejemplo, git) que manejen este problema por usted?

En pocas palabras: ¿existe una estrategia o herramienta estándar de la industria para extraer fácilmente los mensajes de confirmación útiles en los registros de cambios?

Answer 1

Lo he intentado con poca suerte en el pasado. Básicamente, en realidad es más trabajo para que cada desarrollador piense, para cada compromiso, si su mensaje de compromiso es demasiado aterrador para los clientes o no. Los desarrolladores generalmente no son la persona adecuada para tomar esa decisión, y hacerlo un poco a la vez es ineficiente.

Después de mucha experimentación, lo que funcionó para mí es trivial: justo antes de cada lanzamiento, haga que una persona revise el registro de git desde la última versión y anote todas las cosas interesantes en un archivo changelog. Esto realmente no es más trabajo que de otra manera; la mayor parte del trabajo es decidir, no redactar. Y el proceso de decisión requiere una mentalidad particular, por lo que es más eficiente hacer que una persona lo haga en un gran lote que un grupo de desarrolladores que lo hacen poco a poco. (Piénselo de esta manera: no tiene que seguir intercambiando la parte del trabajo de "confirmar y enviar mensajes" dentro y fuera del caché).

Si realmente desea etiquetar los mensajes de confirmación con este tipo de información , al menos debería considerar hacerlo con git notes en lugar del mensaje de confirmación sin formato. Entonces, si alguien lo arruina marcando la confirmación incorrectamente como error/función/etc., puede solucionarlo actualizando la anotación.

Answer 2

No sé de cualquier herramienta estándar, pero ya que no ha recibido una respuesta por un tiempo, aquí están algunas ideas:

Así que, primero, tratando de evitar un fichero de cambios, como se sugerir, probablemente sea una buena idea en general debido a todos los conflictos de fusión que tal archivo tiende a causar. (A menos que tenga una herramienta de combinación automática inteligente)

Algo como un CL: o el prefijo Log: para una fácil extracción es probablemente una buena idea. En cuanto a Add/Ref/Rem/Fix: (Supongo que Ref y Rem significan "Refactor" y "Quitar", ¿no?) Cuando se escribe un registro de cambios, prefiero seguir con las entradas de forma libre. Por ejemplo, no estoy seguro de que las refactorizaciones pertenezcan a un registro de cambios, y las funciones que son de alto nivel para garantizar entradas de registro de cambios no suelen eliminarse por completo, sino que cambian a otras formas.

Pero entonces, ¿cómo abordaría la posibilidad de tener mensajes de compromiso escritos solo para registros de cambios (es decirnivel muy alto);

yo diría, poner la descripción de alto nivel (CL:-etiquetados) en un párrafo del mensaje de confirmación, y la descripción técnica el nivel más bajo en otro párrafo.

o varios mensajes relacionados con el mismo problema de registro de cambios.

Estamos hablando de algo como esto, ¿no?

1. (2011-01-03) CL: Cambiado whizbar defecto a 200.
2. (2011-01-11) CL: Changed whizbar defecto a 150, o 250 si foosnub es cierto.

Y aquí es donde creo que el "registro de cambios automático" se vuelve complicado. A menos que esté dispuesto a volver a establecer la base y editar los mensajes de confirmación después del hecho (como eliminar "CL:" de la confirmación (1) anterior), sugeriría que la única forma práctica de hacerlo es que cada vez que haga un lanzamiento , para extraer todos los párrafos etiquetados del registro de git desde su última versión, y editar manualmente la lista resultante, fusionando elementos como (1) y (2) arriba y, por ejemplo, "Fixed # 145", "Fixed # 153" "," Fixed # 164 "en una sola línea" Fixed # 145, # 153 y # 164 ".

Espero haber sido capaz de proporcionar algo de inspiración. ¡Háganos saber lo que termina haciendo!

Answer 3

Eche un vistazo a vclog.