Come si identificano i commit di bugfix sull'ambiente QA con il repository Git?

3

Mi sono abituato al seguente approccio sulla fase di bugfixing dello sviluppo del progetto. Lo sviluppatore dovrebbe aggiungere il numero di commit SVN come commento al problema JIRA quando lo risolve. Gli ultimi artefatti di CI-server mostrano il numero di build che include la versione principale, il nome del ramo e il numero di commit. Questo approccio aiuta il QA ad identificare facilmente se il bugfix è stato incluso nell'ultima build o meno. Anche quando lo stesso problema è stato riaperto e riparato di nuovo.

Dopo il passaggio da SVN a Git abbiamo perso il numero di commit incrementale. È possibile risolvere questo problema taggando il codice ma i tag sono legati ai numeri sprint. E in caso di riaprire questo problema, questo problema si risolve nel prossimo sprint. Ma il cliente è insoddisfatto del fatto di avere determinati problemi non fissati per diversi sprint.

Quindi, in che modo si identifica il bugfix per l'ambiente QA? Grazie.

UPD: La domanda NON riguarda il collegamento dei problemi ai commit, ma l'abilità dei QA di capire se certe fix (ticket) sono incluse in certe build semplicemente guardando il numero di build e i commenti dei ticket.

    
posta igorp1024 26.09.2014 - 10:23
fonte

3 risposte

2

Che ne dici di utilizzare i tag per contrassegnare i commit?

Guarda questo post su un altro utente che passa da SVN a GIT e ti pone problemi simili, ad es. "Dato che le revisioni svn sono numeri semplici, possiamo usarle per estendere i numeri di versione dei nostri plug-in e build SDK"

Maggiori informazioni su Come si ottiene uno schema di controllo numerico con Git?

    
risposta data 27.09.2014 - 13:33
fonte
2

Potresti voler girare il flusso di lavoro qui - invece di fare in modo che gli sviluppatori visitino un sistema diverso per notare i numeri di commit che puoi far estrarre dai riferimenti i riferimenti ai messaggi del sistema di tracciamento - JIRA supporta commenti appositamente formati che fanno solo questo. Per iniziare, consulta questa pagina .

    
risposta data 27.10.2014 - 21:59
fonte
0

Il comando generale che salta immediatamente su di me è git branch --contains . Ovviamente questo deve essere controllato esplicitamente piuttosto che a colpo d'occhio.

Ma se hai almeno un tag nella tua intera cronologia e mantieni la tua cronologia in gran parte priva di rebases, git describe --tags ti darà una versione lineare.

    
risposta data 27.09.2014 - 19:48
fonte

Leggi altre domande sui tag