Come si diramano i rami di un nome che sono correzioni di bug per un ramo di rilascio in git-flow?

Question

Come si diramano i rami di un nome che sono correzioni di bug per un ramo di rilascio in git-flow?

#1 da (8 voti)

3

Per essere sicuri che tutto il codice passi alla revisione del codice di richiesta pull, abbiamo iniziato a creare rami per le funzioni e le ramificazioni di bug fuori dallo sviluppo seguendo lo stile git-flow.

L'unico problema è che una volta trovato un bug in un ramo di rilascio, spesso dobbiamo fare un ramo fuori dal ramo di rilascio per fare una richiesta di pull al ramo di rilascio. Ma non sembra esserci un ovvio processo di git-flow per la gestione dei rami al di fuori del ramo di rilascio quando si risolve un bug di rilascio.

Qual è il processo git-flow per correggere bug di ramo di rilascio e revisione del codice?

Dovresti risolvere il problema nello sviluppo e creare un nuovo ramo di rilascio? La ramificazione di un ramo di rilascio è ancora valida? Qual è il modo migliore per gestire le revisioni del codice di richiesta pull sulle correzioni dei bug del ramo di rilascio?

git branching gitflow

posta Mark Rogers 04.07.2017 - 22:36

fonte

1 risposta

Leggi altre domande sui tag git branching gitflow

Come condividere lo stesso comportamento in classi diverse? Come si progetta un buffer per una console?

score 8 · Accepted Answer

Dal tuo aggiornamento ti stai chiedendo di una release che non è stata distribuita ai prod. Suppongo che ciò significhi che non hai ancora unito il master o taggato il commit.

In git-flow, puoi correggere eventuali bug direttamente sul ramo di rilascio. Vedi lo schema qui sotto:

I documenti di git-flow che ho letto dicono esplicitamente

any problems are fixed directly in the release branch

Penso che la logica sia che questi bug dovrebbero essere piccoli elementi relativi al rilascio, e miglioreranno il ciclo di test di rilascio evitando i rami di bug-fix. Sebbene la logica sia valida, credo sia meglio assicurarsi che il codebase sia protetto, e i processi di revisione del codice non dovrebbero essere sovvertiti perché una release deve uscire dalla porta. Dato che hai una politica di revisione del codice, ti consiglio di fare esattamente quello che stai già facendo. Crea una sezione di bug fix dal ramo di rilascio, esegui il commit del ramo bug-fix e invia un PR dal ramo bug-fix per rilasciare il ramo - indipendentemente da ciò che dicono i documenti. Dopo tutto, la strategia delle filiali dovrebbe essere adattata alle tue esigenze, non viceversa.