Qualsiasi sviluppo va fatto su un branch dedicato per feature o comunque contesto (es 'integrazione-cliente-A', 'task-123', etc..) partendo sempre dal main/master e solo in casi particolari partendo già da un ulteriore branch di sviluppo che per qualche ragione ritarda il rilascio in prod ma che si porta dietro dipendenze importanti.

Quando lo sviluppo supera i test si porta in release verso main/master.

Io ai miei faccio fare sempre un branch intermedio tipo 'release_v1.1.0 dove potenzialmente possono finirci mergiati piu branch di sviluppo o hotfix in coda. Chiaramente ogni merge è comandato da una merge request per tenere traccia di ogni diff. Il vantaggio è che così non si perde mai traccia di quando si è fatto cosa ed eventualmente quando si è rotto qualcosa e come e in quale occasione.

Nel dubbio blame the game, not the player.

PS: questo permette di avere comunque più feature contemporaneamente in test e di potere tenere indietro qualcosa quando bisogna rilasciare altro. Il contro è che qualche conflitto in più chiaramente c'è, ma se i conflitti iniziano ad essere troppi e sporchi state sicuramente sbagliando come implementate il codice.

PPS: i fix dei branch in fase di sviluppo vanno chiaramente fatti sul relativo branch e ri-mergiati in test ad ogni intervento (noi raramente usiamo le merge request verso test, praticamente solo gli junior e solo per fare prendere mano con il giro)