Il riferimento a bug / problema nel messaggio di commit è considerato una buona pratica?

11

Sto lavorando a un progetto in cui è impostato il controllo del codice sorgente per scrivere automaticamente le note nel bug tracker. Scriviamo semplicemente l'ID di emissione del bug nel messaggio di commit e il messaggio di commit viene aggiunto come nota al tracker dei bug.

Vedo solo alcuni aspetti negativi di questa pratica. Se in futuro il codice sorgente viene separato dal software di tracciamento dei bug (o i bug / problemi segnalati vengono in qualche modo persi). O quando qualcuno sta guardando nella cronologia dei commit ma non ha accesso al nostro bug tracker.

La mia domanda è se avere un riferimento di bug / problema nel messaggio di commit è considerato una buona pratica? Ci sono altri aspetti negativi?

programming-practices version-control issue-tracking

— Christian P
fonte

10

Abbiamo adottato questa pratica e funziona molto bene per noi. La stretta integrazione tra il sistema di controllo versione (VCS) e altri sistemi che utilizziamo, ad esempio integrazione continua, bug tracker, ecc. È estremamente preziosa. Se dovessimo mai cambiare qualcosa in futuro, dovremo sicuramente valutare gli effetti collaterali, inclusi i collegamenti tra il VCS e il sistema di tracciamento dei bug.

In generale, lo considero una buona pratica. Per alcuni sistemi di tracciamento sono disponibili opzioni e strumenti aggiuntivi, ad esempio proprietà bugtraq per Subversion (SVN). Ciò suggerisce che molte persone vedono valore in questa pratica.

— Manfred
fonte

13

Se vuoi assicurarti davvero, davvero che nessuna informazione venga persa anche se in futuro potresti utilizzare un tracker bug diverso o i dati del tracker bug in qualche modo scompaiono, perché non inserire l'ID problema e una breve spiegazione del bug in il messaggio di commit?

Correzione del bug n. 123: app bloccata dopo l'accesso

Quindi hai ancora il link dalla cronologia dei commit al tracker dei bug - e se il tracker dei bug non dovesse mai essere disponibile, puoi ancora vedere nella storia di cosa trattava questo particolare bug.

— Christian Specht
fonte

In realtà lo facciamo, quindi non dobbiamo passare al bug tracker ogni volta che navighiamo nella cronologia dei commit.

— Christian P,

Bene, allora lo lascerei così com'è. IMO, questo è il modo migliore come puoi farlo!

— Christian Specht,

1

Sì, buon punto. Comunque, quella era la mia ipotesi. Solo l'ID bug / issue da solo non è abbastanza buono nella mia esperienza. Guardando il registro di commit si desidera ancora vedere di cosa trattava ciascun commit, ad esempio qual è stato il motivo principale di questo cambiamento di codice. A volte il messaggio di commit è più sul lato tecnico mentre il testo per il sistema di tracciamento dei bug è più orientato verso gli utenti del software.

— Manfred,

Questa è stata generalmente la pratica standard in cui ho lavorato anche, penso che sia il modo giusto per farlo.

— Carson63000,

+1 fallo sempre! Ho appena assunto la manutenzione di un progetto pieno di gemme come "questa potrebbe essere stata la causa del bug 5423" Non abbiamo accesso al loro bug tracker.

— Kryptic,

2

Questa è una pratica molto comune e l'ho trovata estremamente conveniente. Uso TRAC, in modo da poter leggere la cronologia del codice e accedere all'attività che ha guidato la modifica, oppure leggere la cronologia dell'attività e accedere alle modifiche al codice.

"Se in futuro ..." Se si separa il codice dal tracker dei bug, probabilmente la vecchia cronologia delle revisioni non sarà di ulteriore interesse.

— Kevin Cline
fonte

2

Uso anche questa pratica e la considero un'ottima. Ma oltre all'ID problema, aggiungo una breve descrizione del bug / funzionalità (di solito il titolo dal sistema di tracciamento dei bug). Questo spesso aiuta a risparmiare tempo perché non devo cercare nel sistema di tracciamento dei bug (perché riconosco la modifica) E, come hai detto tu, se in qualche modo perdo il sistema di tracciamento dei bug, non mi perdo completamente.

— Nicolae Albu
fonte