Sì, il flusso di lavoro gitflow sembra mancare questo senario.
Un ramo di aggiornamento rapido viene unito nuovamente al master e si sviluppa una volta completato. Ma non il ramo di rilascio!
Una volta completato il tuo ramo di rilascio, questo verrà unito al master e potenzialmente avrà un conflitto o introdurrà un bug, quindi questa non è una buona cosa.
Suggerirei di unire il master nel rilascio dopo aver completato l'aggiornamento rapido. questo porterà il tuo ramo delle funzionalità aggiornato con il master e ti consentirà di testare l'aggiornamento rapido nella nuova versione.
Tuttavia, un'alternativa sarebbe quella di unire l'aggiornamento rapido in master, sviluppare AND il ramo di rilascio. puoi vedere che questo sarebbe difficile da automatizzare poiché il nome del ramo di rilascio cambierà ogni volta.
(molte persone preferiscono rebase per unire, ma non permettono di entrare in quello)
** modifica **
C'è un'altra possibilità se trovi che questo sta accadendo molto.
- Ripristina la versione live a quella precedente.
- Aggiungi la correzione alla prossima versione
- Distribuisci la correzione con la prossima versione
Ovviamente questo ti lascia con una vecchia versione dal vivo, ma se fai costantemente delle correzioni rapide ti indica un problema nel tuo processo di test e rilascio.
Spingere per i rollback anziché le hot fix può essere una buona cosa. Tutti sono più felici quando le versioni vengono distribuite senza problemi e senza fretta per completare i rilasci delle correzioni rapide, ma la correzione rapida essenzialmente nasconde i problemi al business. Se si richiede un rollback, questo può focalizzare l'attività lasciando più tempo per i test e il completamento delle funzionalità. Nel lungo periodo questo può aumentare la velocità di sviluppo.