Dove vanno le correzioni dei bug nel modello git-flow?

Negli hotfix del modello Git-flow , comunemente indicati come, vanno nel loro hotfix-*ramo specifico e piccole correzioni di integrazione proprio prima del rilascio vanno nel release-*ramo. Le correzioni generali della versione precedente non sembrano avere un posto.

Dove dovrebbero apparire? Dovrebbero essere nel loro bug-*ramo che si dirama develop(proprio come i featurerami)?

git gitflow

— Scarpa
fonte

Perché un bug non critico nel codice rilasciato sarebbe diverso da una piccola funzionalità per produrre un comportamento diverso rispetto a quello attualmente applicato dall'applicazione?

— Bart van Ingen Schenau,

@BartvanIngenSchenau Li consiglieresti come feature-*filiali? Una correzione su un comportamento errato può essere vista come una caratteristica?

— Scarpa

@Shoe Penso che Bart significhi che dovresti trattarli come caratteristiche, non necessariamente usando lo stesso prefisso del ramo .

— Darkhogg,

@Shoe: in git-flusso, qualsiasi ramo eccezione master, develop, release-*o hotfix-*è un ramo di caratteristica, in modo da poter utilizzare qualsiasi prefisso ti piace e utilizzare un prefisso diverso per i bug. Inoltre, qual è la differenza tra comportamento errato che funziona come specificato e comportamento errato che si discosta dalle specifiche? In entrambi i casi si tratta di un comportamento errato, ma solo l'ultimo è un bug.

— Bart van Ingen Schenau,

La risposta breve: Sì, i rami per le correzioni di bug che entreranno in una prossima versione pianificata dovrebbero trovarsi nei rami delle funzionalità. Il modo in cui nominate i rami delle caratteristiche o questi rami per le correzioni di bug dipende da voi e dagli standard del vostro team, ma dovrebbero essere trattati in modo identico se seguite Gitflow.

Il commento di Bart van Ingen Schenau solleva un buon punto.

Gitflow ha cinque tipi di filiale: master, develop, rami di aggiornamento rapido (con prefisso hotfix-), rami di rilascio (con prefisso release-, e dispongono di rami Il. masterE developrami sono rami di lunga durata e non si impegnano direttamente in loro i. release-Rami sono fatti per disegnare una linea per una versione particolare e quindi supportare correzioni di bug tra l'identificazione della versione successiva e la versione. I hotfix-rami sono specificamente per le versioni critiche, fuori ciclo di produzione. I feature-rami sono per lo sviluppo di funzionalità individuali per alcune versioni future.

Venendo da ambienti in cui si utilizzano PR e, a parte un singolo sviluppatore di impegnarsi in un ramo di caratteristica, nulla deve essere impegnato direttamente nella master, developo un ramo di release. Questo assicura che ogni modifica venga revisionata dal codice, oltre a garantire un'adeguata copertura dei test e passare i test in un ambiente CI prima che entrino in vigore le modifiche. Sarei contrario a qualsiasi commit direttamente in uno di questi rami, anche se sembra che Gitflow da solo non lo faccia ' non ci sono problemi nel commettere correzioni di bug pre-release o modifiche direttamente nel ramo di rilascio e quindi nel tirarle nello sviluppo e quindi nei rami delle caratteristiche.

Nel tuo caso particolare, una release-filiale non è un posto appropriato. Il software è già stato rilasciato ed è disponibile master. Una volta che una versione è unita in master e taggata lì, il ramo di rilascio per quella particolare versione ha superato il suo scopo e non deve necessariamente più esistere. Se sei attivo nel ripulire i tuoi rami (cosa che penso dovrebbero essere tutti), allora questa non è nemmeno un'opzione.

Se la correzione non è critica, non sembra adattarsi nemmeno a un ramo di aggiornamento rapido. Lo scopo di un ramo hotfix è quello di consentire a qualcuno di ottenere cambiamenti critici nella produzione molto rapidamente senza interferire con lo sviluppo in corso. L'uso di questi dovrebbe essere l'eccezione piuttosto che la norma per un team di sviluppo. In generale, gli hotfix critici dovrebbero essere un caso eccezionale.

L'unica cosa rimasta è un ramo di funzionalità. Si noti che la sezione della pagina collegata alla domanda sui rami delle caratteristiche dice anche che i rami delle caratteristiche sono "a volte chiamati rami degli argomenti". Se la modifica è destinata a qualsiasi versione imminente e non soddisfa i criteri per un aggiornamento rapido, dovrebbe trovarsi in uno di questi rami.

— Thomas Owens
fonte

Conveniamo che non dovrebbero esserci impegni diretti per padroneggiare, sviluppare o rilasciare filiali. Ma quale dovrebbe essere il flusso di PR quando trovi un bug nel ramo di rilascio e deve essere corretto in entrambi i rami, rilascio e sviluppo. Questo ha le sue sfide se il tuo intero ramo di rilascio non è ancora pronto per essere unito in sviluppo, ma la correzione di bug dovrebbe essere fatta in entrambi i posti .. Se vuoi, posso pubblicare una nuova domanda per questo.

— Sap

@Sap Una nuova domanda sarebbe buona, ma se la pubblichi, ti preghiamo di spiegare perché la correzione è così critica che deve essere unita in entrambe - questo sembra implicare che non è stato trovato un problema critico prima che fosse introdotto develop, non trovato tra il momento in cui è stato introdotto e la creazione del ramo di rilascio e / o che il ramo di rilascio esiste da molto tempo. Semplicemente, tuttavia, credo che l'unica scelta sia una scelta ciliegia (suggerirei una correzione e tirerei una richiesta nel ramo di rilascio, unirei nel ramo di rilascio, e ciliegia-pick in sviluppo tramite una richiesta pull).

— Thomas Owens

Se si tratta di un singolo commit, esegui un commit ben identificato e spingilo in cima al ramo di sviluppo, altrimenti crea un ramo di funzionalità.

C'è anche un commento dell'autore git-flow che dice esattamente quello che stai chiedendo: Missf bugfix rami # 24

— debuttante
fonte

Grazie, quel link che hai condiviso mi ha chiarito.

— arcseldon,