Risposte:
Io uso
[Abc]: Message.
Con Add, Mod (ify), Ref (actoring), Fix, Rem (ove) e Rea (dability) è facile estrarre il file di log.
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 prima cosa più importante.
Mode Ref? A volte sto solo facendo piccole correzioni che è una sorta di refactoring.
Modriguarda l'aggiunta di qualcosa o il cambiamento di un comportamento, la Refmodifica di elementi interni che non aggiungono alcuna funzionalità, aggiunta di API, ecc. Esempio: se ho una add(Object)funzione e implemento una add(List<Object>)funzione, commenterò Mod. Successivamente rimuoverò la duplicazione e utilizzerò direttamente add(Object)in add(List<Object>)poi userò Ref.
Usiamo quanto segue:
[ID ticket in JIRA]: [Messaggio: cosa è stato fatto] Ad esempio - ABC-123: Aggiunta la possibilità di configurare la presentazione per regione.
In questo caso, con una corretta integrazione, sarai in grado di ottenere file modificati / cancellati / aggiunti nel tracker dei problemi. Tuttavia, tieni presente che dovresti prevenire qualcosa come ABC-123: Fatto o ABC-123: Risolto con i filtri, se possibile.
Esiste una semplice regola, che è una convenzione seguita da molti (se non tutti) SCM e dalla maggior parte degli strumenti che funzionano con gli SCM:
La prima riga di un messaggio di commit è un breve riepilogo, mentre il resto del messaggio contiene i dettagli.
Pertanto, la maggior parte degli strumenti visualizza solo la prima riga e visualizza l'intero messaggio su richiesta.
Un uso improprio tipico di un messaggio di commit è un elenco puntato di modifiche (verrà mostrato solo il primo punto elenco). Un altro uso improprio è la scrittura di un messaggio dettagliato su una singola riga.
Quindi, se c'è una cosa da far valere, direi che è la lunghezza massima della prima riga.
Personalmente non ho mai visto un modello di commit generale che vale la pena usare. Il commento dovrebbe dire concisamente a cosa sono collegati i commit, ad es. Quale funzione / correzione di bug o una breve dichiarazione del perché sono state apportate modifiche.
Le informazioni su ciò che è stato commesso non devono essere incluse, questo può essere determinato dal sistema scm. Ulteriori informazioni su bug / funzionalità appartengono a dove vengono mai rilevati bug e funzionalità.
Quando aggiorno una segnalazione di bug dopo un commit, trovo che sia utile indicare anche la revisione del commit insieme ai commenti nella segnalazione di bug. In questo modo puoi trovare la strada dal commento di commit alla segnalazione di bug e per ogni commento sulla segnalazione di bug puoi trovare ciò che è stato commesso, ma non duplicare le informazioni disponendole sia sulla segnalazione di bug sia sul messaggio di commit.
Quindi, quando si visualizza la cronologia delle revisioni di un file, sono disponibili brevi brevi messaggi che descrivono la cronologia, ma si sa anche dove cercare ulteriori dettagli, segnalazioni di errori o descrizioni di attività per ulteriori dettagli.
In Git è possibile applicare quasi tutto con i ganci Git . Controlla gli esempi in .git / hooks per idee.
Per quanto riguarda il messaggio, in un caso molto generale, vuoi includere sufficienti informazioni sul problema che stavi risolvendo E sulla soluzione stessa per poter trovare e identificare questo commit in un secondo momento. Nella maggior parte dei casi al problema verrà indicato un numero di bug (con una corretta integrazione con il sistema di tracciamento dei bug). Se hai altri sistemi con cui il tuo 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 vuoi renderlo semplice. Altrimenti, le persone troveranno un modo per ingannare il sistema e produrre messaggi di commit inutili.
Usiamo un modello contenente
I primi due vengono comunque omessi per la maggior parte del tempo (occasionalmente tutti e tre) quindi non è un grosso problema.
In genere ho l'identificatore presente nel sistema di tracciamento dei biglietti che utilizzo o una panoramica di alto livello come prima riga. Quindi ho punti "bullet" dell'elemento pubblicitario della modifica specifica nel commit. Quindi potrei avere qualcosa del tipo:
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, potrei semplicemente prendere tutti i messaggi di commit e analizzarlo in un registro delle modifiche molto facilmente.
[ticketId] [ABC] [topicId] [WIP] Messaggio, dove:
Esempi:
[# 452567] [aggiungi] [menu_item] nuovo elemento - guestbook
[# 452363] [fix] [banner_top] [WIP] 1024x300 può essere usato ora
[# 452363] [fix] [banner_top] 500x200 ora può essere usato
[ # 452713] [rem] [page] annuncio centrale a sinistra