Strategia per estrarre i messaggi della maggior parte dei commit utili per changelog

Question

Le esigenze per questa domanda è quello di

• hanno un changelog per manager/clienti che:
  • include "Che gli utenti hanno indirizzi aggiuntivi"
  • non include "Corretto il bug in cui gli indirizzi sono stati sovrascritti a causa di X"
• evitare di dover guardare attraverso log completo la storia per trovare i commit più importanti (il più delle volte all'indietro incompatibili) per ogni generazione
• rendere il più facile da leggere come il changelog tipico gioco ("problemi di bilanciamento fissi: X" e "Grafica autista Y reso il gioco lento ")

Oggi, stiamo usando bandiere in messaggi di commit come

Add|Ref|Rem|Fix: <msg> per il solito commettere.

Come tale, il mio primo tentativo di questo sarebbe quello di aggiungere un altro livello di quelle bandiere, per esempio

CL-Add: feature X (CL = changelog) e quindi analizzare tutti i messaggi di commit per ^CL-(Add|Ref|Rem|Fix) aggiungere al changelog.

Ma allora, come ti avvicineresti alla possibilità di avere messaggi di commit scritti solo per i changelog (cioè un livello troppo alto); o più messaggi riguardanti lo stesso problema di registro delle modifiche. Forse i messaggi di log del changelog dovrebbero essere estratti quando i branch di feature vengono uniti? Ci sono caratteristiche di SCM: s (ad esempio git) che gestisce questo problema per te?

In poche parole: esiste una strategia standard di settore, o uno strumento, per estrarre facilmente i messaggi di commit utili nei log delle modifiche?

Answer 1

L'ho provato io stesso con poca fortuna in passato. Fondamentalmente, è in realtà altro lavorare per far credere a ogni sviluppatore, per ogni commit, se il loro messaggio di commit è troppo spaventoso per i clienti o meno. Gli sviluppatori non sono generalmente la persona giusta per prendere questa decisione, e farlo un po 'alla volta è inefficiente.

Dopo molte sperimentazioni, ciò che ha funzionato per me è banale: appena prima di ogni rilascio, una persona deve passare attraverso il registro git dall'ultima versione e scrivere tutte le cose interessanti in un file di log delle modifiche. Questo in realtà non è più un lavoro dell'altro modo; la maggior parte del lavoro sta decidendo, non il fraseggio. E il processo decisionale richiede una mentalità particolare, quindi è più efficiente avere una persona che lo fa in un grosso lotto rispetto a un gruppo di sviluppatori che fanno un pochino alla volta. (Pensalo in questo modo: non devi continuare a scambiare il "commit message customer checking" parte del lavoro dentro e fuori dalla cache.)

Se vuoi davvero taggare messaggi di commit con questo tipo di informazione , si dovrebbe almeno considerare di farlo con git notes invece del messaggio di commit non elaborato. Quindi se qualcuno lo rovina segnando il commit in modo errato come bug/feature/etc, puoi correggerlo aggiornando l'annotazione.

Answer 2

non so di tale strumento standard, ma dal momento che non hanno ottenuto una risposta per un po ', ecco alcune idee:

Quindi, prima, cercando di evitare un file changelog, come si suggerire, è probabilmente una buona idea in generale a causa di tutti i conflitti di fusione che un file tende a causare. (A meno che non si disponga di uno strumento di unione automatico intelligente.)

Qualcosa come un CL: o Log: il prefisso per una facile estrazione è probabilmente una buona idea. Per quanto riguarda Aggiungi/Rif/Rem/Correzione: (presumo che Ref e Rem significano "Refactor" e "Remove", giusto?). Quando scrivi un log delle modifiche, preferirei inserire le voci in formato libero. Ad esempio, non sono sicuro che i refactoring appartengano a un log delle modifiche e le funzionalità di livello abbastanza elevato da garantire che le voci di changelog non vengano rimosse in modo definitivo - piuttosto vengono modificate in qualche altra forma.

Ma allora, come ti avvicineresti alla possibilità di avere messaggi di commit scritti solo per i changelog (ad es.livello troppo alto);

direi, mettere la descrizione (CL: -tagged) di alto livello in un paragrafo del messaggio di commit, e il livello inferiore descrizione tecnica in un altro punto.

o più messaggi relativi allo stesso problema di registro delle modifiche.

Stiamo parlando di qualcosa del genere, giusto?

1. (2011-01-03) CL: Modificato whizbar predefinita 200.
2. (2011-01-11) CL: cambiato whizbar predefinita 150, o 250 se foosnub è vero.

E questo è dove penso che la cosa del "cambio automatico del log" sia complicata. A meno che non sia disposto a rebase e modificare i messaggi di commit dopo il fatto (come rimuovere "CL:" da commit (1) sopra), suggerirei che l'unico modo pratico per fare questo è, ogni volta che si rilascia una versione , per estrarre tutti i paragrafi taggati dal log git dall'ultima release e modificare manualmente l'elenco risultante, unendo elementi come (1) e (2) sopra e girando, ad esempio, "Fisso # 145", "Fisso # 153 "," Risolto # 164 "in una singola riga" Fisso # 145, # 153 e # 164 ".

Spero di essere stato in grado di fornire qualche ispirazione. Facci sapere cosa stai facendo!

Answer 3

Dai un'occhiata allo vclog.