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

Naviga le tue risposte
11

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

Posso vedere solo alcuni aspetti negativi di questa pratica. Se in futuro il codice sorgente viene separato dal software di tracciamento dei bug (o gli errori / problemi segnalati sono 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 bug / riferimento al problema nel messaggio di commit è considerato una buona pratica? Ci sono altri aspetti negativi?

    
posta Christian P 24.11.2011 - 21:33
fonte

4 risposte

10

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

In generale, vedrei questa come 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.

    
risposta data 24.11.2011 - 21:51
fonte
13

Se vuoi essere veramente sicuro che nessuna informazione vada perduta, anche se in futuro potresti utilizzare un bug tracker diverso o se i tuoi dati di bug tracker scompariranno in qualche modo, perché non inserire l'ID del problema e una breve spiegazione sul bug nel messaggio di commit?

Fix bug #123: app crashed after login

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

    
risposta data 24.11.2011 - 22:22
fonte
2

Questa è una pratica molto comune e l'ho trovata estremamente comoda. Io uso TRAC, così posso leggere la cronologia del codice e navigare verso l'attività che ha guidato la modifica, o leggere la cronologia delle attività e navigare verso le modifiche al codice.

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

    
risposta data 24.11.2011 - 22:17
fonte
2

Anche io uso questa pratica e la considero molto buona. Ma oltre all'ID problema, aggiungo una breve descrizione del bug / funzionalità (di solito il titolo del sistema di tracciamento dei bug). Questo spesso aiuta a risparmiare tempo perché non devo cercare nel sistema di tracciamento dei bug (perché riconosco il cambiamento) E, come hai detto tu, se in qualche modo perdo il sistema di tracciamento dei bug, non sono completamente perso.

    
risposta data 24.11.2011 - 22:36
fonte

Leggi altre domande sui tag

I file oggetto (C) creati con diversi compilatori sono compatibili con i binari? È legale / morale ripubblicare il progetto oss di un autore che non risponde?