Esiste uno svantaggio per il commit di messaggi contenenti il numero del ticket

Sì, questa è una buona idea e pratica abbastanza standard (ma non universale).

L'obiettivo specifico di ingegneria del software che stai conseguendo con questo è tracciabilità dei requisiti . L'idea è di voler essere in grado di tracciare un requisito attraverso l'intero processo del software:

1. Requisiti aziendali
2. Requisiti funzionali
3. Requisiti tecnici
4. Manufatti del codice
5. feedback del QA
6. Correzioni di sviluppo

Utilizzando i numeri di ticket o di requisiti (ad esempio ID Jira Story) nei messaggi di commit e in qualsiasi corrispondenza, stai lavorando per raggiungere l'obiettivo di ingegneria del software.

Se torno un anno dopo e vedo il messaggio di commit, posso cercare quel numero in un altro sistema per ottenere lo sfondo completo dietro il requisito o il ticket, incluso tutto ciò che si è verificato dopo il commit .

Se il tuo sistema tiene traccia di tutte le funzionalità / bug, probabilmente avrai un ticket di qualche tipo. Ma se il tuo sistema tiene traccia solo di bug (per qualche motivo?) E tutto il nuovo sviluppo è gratuito per tutti.

Alcuni vantaggi significativi:

• Alcuni VCS / sistemi di biglietti consentono collegamenti ipertestuali automatici per il numero del biglietto durante la navigazione dei commit nel tracker dei problemi (questo è super utile, vedi github , redmine )
• Fornisce un contesto per l'inevitabile "perché Simon ha fatto questo? Non ha senso!" domanda
  • Spesso potrebbe essere anni più tardi ...
  • Il contesto per le modifiche può richiedere molto lavoro per molti anni in futuro. Avere un ticket con una spiegazione per perché il codice è stato modificato può essere super, super utile
• Aiuta le persone a lavorare su cose che aggiungono valore
  • "Oh, ho intenzione di refactoring questo .. e questo .. e questo ... e ... oh non ho fatto alcun valore-aggiungere lavoro in una settimana!"
• Può consentire alle ricerche di trovare commit relativi a un problema

L'unico svantaggio è se la tua squadra non utilizza realmente i biglietti o un sistema di tracciamento. Quindi sarebbe più difficile trovare il numero del biglietto. Oppure se il tuo VCS e il tuo tracker non si integrano bene.

E ... dovresti tenere traccia di tutti gli sforzi da qualche parte, quindi, se è per questo che non stai utilizzando un sistema di ticket per quasi tutto il tuo lavoro, ti suggerisco caldamente di farlo, indipendentemente dal fatto che sia incluso nel tuo commit messaggi.

Il rovescio della medaglia è che le persone scrivono meno commenti di commit completi perché qualcuno può andare al ticket per maggiori dettagli. Questo è davvero un problema se si dice di passare a un sistema di ticketing diverso e non si può mantenere la cronologia o qualcuno non ha un sistema di ticketing ma ha accesso al repository.

Se il ramo è già denominato per il ticket, non mi preoccuperei di inserirlo nel commit, che sembra ridondante.

Includere numeri di riferimento (ticket, caratteristiche, requisiti, etc .) nei messaggi di commit è una grande idea. Ma non dovrebbe mai essere un sostituto di un buon messaggio. Al mio attuale datore di lavoro, siamo ora sul nostro secondo sistema di controllo della fonte, il nostro terzo sistema di ticketing e il nostro secondo sistema di gestione dei requisiti. Inutile dire che i dati dei vecchi sistemi non sono mai stati migrati nelle loro sostituzioni, e anche se lo fossero, i sistemi di numerazione si sovrappongono.