Puoi raccomandare un buon modello di messaggio di commit / linee guida da applicare in azienda? [chiuso]

Io uso

[Abc]: Message.

Con Aggiungi, Mod (ify), Ref (Attuazione), Correzione, Rem (ove) e Rea (daabilità), è facile estrarre il file di registro.

Esempio:

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.  

Se ho più di una riga, li seleziono per primi in ordine di importanza.

Usiamo il seguente:

[ID ticket in JIRA]: [Message: What was done] Ad esempio: ABC-123: aggiunta la possibilità di configurare la presentazione per regione.

In questo caso, con un'integrazione corretta, sarai in grado di ottenere file modificati / cancellati / aggiunti nel tuo tracker di problemi. Tuttavia, tieni presente che dovresti evitare qualcosa come ABC-123: Fatto o ABC-123: corretto con i filtri, se possibile.

C'è una sola regola, che è una convenzione seguita da molti (se non tutti) SCM e dalla maggior parte degli strumenti che funzionano con SCM:

The first line of a commit message is a short summary, while the rest of the message contains the details.

Quindi, la maggior parte degli strumenti visualizza solo la prima riga e visualizza l'intero messaggio su richiesta.

Un tipico uso improprio di un messaggio di commit è un elenco puntato di modifiche (verrà mostrato solo il primo punto). Un altro uso improprio è la scrittura di un messaggio mooolto dettagliato su una singola riga.

Quindi, se c'è una cosa da far rispettare, direi che è la lunghezza massima della prima linea.

Personalmente non ho mai visto un modello di commit generale che valga la pena di usare. Il commento dovrebbe concisamente dire quali sono i commit relativi ad es. quale correzione di funzionalità / bug o una breve dichiarazione del motivo per cui sono state apportate modifiche.

Le informazioni su ciò che è stato commesso non dovrebbero essere incluse, questo può essere determinato dal sistema scm. Altre informazioni su bug / funzionalità appartengono a dove vengono tracciati bug e funzionalità.

Quando si aggiorna una segnalazione di bug dopo un commit, trovo utile anche dichiarare la revisione di commit insieme ai commenti nella segnalazione di bug. In questo modo puoi trovare la tua strada dal commento di commit alla segnalazione di bug, e per ogni commento sul bug report puoi trovare ciò che è stato commesso, ma non duplicare le informazioni disponendole sia sul bug report che sul messaggio di commit.

Quindi, quando visualizzi la cronologia delle revisioni per un file, hai dei bei messaggi brevi che descrivono la cronologia, ma sai anche dove cercare maggiori dettagli dei bug report o descrizioni delle attività per maggiori dettagli.

In Git è possibile applicare praticamente qualsiasi cosa con Git git . Controlla gli esempi in .git / hooks per le idee.

Per quanto riguarda il messaggio, in un caso molto generale, si desidera includere abbastanza informazioni sul problema che si stava risolvendo e la soluzione stessa per essere in grado di trovare e identificare questo commit in seguito. Nella maggior parte dei casi il problema verrà riferito a un numero di bug (con una corretta integrazione con il sistema di tracciamento dei bug). Se hai altri sistemi con cui il processo si integra (come il sistema di tracciamento della revisione del codice), includi anche i bit appropriati:

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

MA tu vuoi essere semplice. Altrimenti, le persone troveranno un modo per ingannare il sistema e produrre messaggi di commit inutili.

Utilizziamo un modello contenente

• Il numero identificativo del bug / funzione / correzione
• Un sì / no che descrive se il codice è stato testato o meno
• E una sezione di dettagli per una breve descrizione dell'intenzione del commit

I primi due vengono comunque omessi per la maggior parte del tempo (a volte tutti e tre) quindi non è un grosso problema.

Generalmente ho l'identificatore che si trova nel sistema di tracciamento dei biglietti che utilizzo o una panoramica di alto livello come prima linea. Poi ho punti "bullet" dell'elemento pubblicitario della modifica specifica nel commit. Quindi ho potuto qualcosa di simile:

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

Questo è il formato di commit più pulito che mi piace. È diretto e al punto. Un altro motivo per cui lo faccio in questo modo è che se voglio creare un registro delle modifiche, posso semplicemente prendere tutti i messaggi di commit e analizzarlo in un registro delle modifiche molto facilmente.

[ticketId] [ABC] [topicId] [WIP] Messaggio, dove:

• ID ticketID - ID di un elemento nel repository di attività
• ABC - add (funzione), correzione (bugfix), str (struttura), dep (dipendenza) rem (incompatibilità / rimozione all'indietro), rea (leggibilità), ref (refactoring)
• topicId - può essere un selettore di lavoro per jenkins e / o nome di ramo e / o nome di argomento per gerrit
• WIP: work in progress / o not (cioè l'integrazione continua potrebbe richiedere questo)
Messaggio
• - dettagli della modifica

Esempi:
[# 452567] [aggiungi] [menu_item] nuovo elemento - libro degli ospiti
[# 452363] [correzione] [banner_top] [WIP] 1024x300 può essere utilizzato ora
[# 452363] [correzione] [banner_top] 500x200 può essere usato ora
[# 452713] [rem] [pagina] annuncio centrale a sinistra