Negli, comunemente detti, Git-flow gli hotfix dei modelli vanno nella loro il ramo hotfix-* specifico e le piccole correzioni per l'integrazione subito prima del rilascio vanno nel ramo release-* . Le correzioni di bug generali della versione precedente non sembrano avere un posto.
Dove dovrebbero apparire? Dovrebbero essere nel loro bug-* branch branching off di develop (proprio come feature branches)?
La risposta breve: Sì, i rami per le correzioni di bug che stanno per essere implementati in una prossima versione dovrebbero essere nei rami delle funzionalità. Il modo in cui denominate le branch delle funzionalità o questi rami per le correzioni dei bug dipende da voi e dagli standard del vostro team, ma dovrebbero essere trattati in modo identico se state seguendo Gitflow.
commento di Bart van Ingen Schenau mostra un buon punto.
Gitflow ha cinque tipi di diramazione: master , develop , rami di aggiornamento rapido (prefissati con hotfix- ), rami di rilascio (con prefisso release- e rami di funzione. I rami master e develop sono rami di lunga durata e non vi impegnate direttamente in essi. I rami release- vengono creati per disegnare una linea per una particolare versione e quindi supportano correzioni di bug tra l'identificazione della prossima versione e della release. I rami hotfix- sono in particolare per rilasci critici e fuori ciclo in produzione. I rami feature- servono per lo sviluppo di singole funzionalità per alcune versioni future.
Provenienti da ambienti in cui vengono utilizzati i PR e, a parte uno sviluppatore individuale che si impegna su un ramo di funzionalità, nulla deve essere impegnato direttamente in master , develop o un ramo di rilascio. Ciò garantisce che ogni cambiamento venga rivisto dal codice, assicurando un'adeguata copertura del test e superando i test in un ambiente CI prima che le modifiche entrino. Sarei contrario a qualsiasi commit direttamente in uno di questi rami, anche se sembra che Gitflow da solo non lo faccia Non ho alcun problema con il commit di correzioni di bug pre-release o modifiche direttamente nel ramo di rilascio e poi estraendole nello sviluppo e quindi nei rami delle funzionalità.
Nel tuo caso particolare, un ramo release- non è un luogo appropriato. Il software è già stato rilasciato ed è in master . Una volta che il rilascio è stato fuso in master e taggato lì, il ramo di rilascio per quella particolare release è sopravvissuto al suo scopo e non ha necessariamente bisogno di esistere più. Se sei attivo nel ripulire i tuoi rami (che penso che dovrebbero essere tutti), allora questa non è nemmeno un'opzione.
Se la tua correzione non è critica, allora un ramo di hotfix non sembra adattarsi a nessuno dei due. Lo scopo di un ramo di aggiornamento rapido è consentire a qualcuno di apportare modifiche critiche alla produzione molto rapidamente senza interferire con lo sviluppo in corso. L'utilizzo 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à. Tieni presente che la sezione della pagina collegata alla domanda sui rami delle funzionalità dice anche che i rami di funzionalità sono "a volte chiamati rami argomento". Se la tua modifica ha come target qualsiasi versione imminente e non soddisfa i criteri per una correzione, dovrebbe trovarsi in uno di questi rami.
Se si tratta di un singolo commit, basta creare un commit ben identificato e inserirlo sopra il ramo di sviluppo, altrimenti creare un ramo di funzionalità.
C'è anche un commento dell'autore del git-flow che dice esattamente quello che stai chiedendo: Missing bugfix branches # 24