Se ti capisco correttamente, il tuo processo attuale significa che prima di un rilascio, il ramo Principale avrà i check-in per la caratteristica A, la caratteristica B e Bug Fix C. Quando pianifichi un rilascio, unirai il check-in per Feature A e Bug Fix C nel ramo Release, lasciando le modifiche per Feature B nel ramo Main per una release futura. È corretto?
In tal caso, si sta essenzialmente utilizzando una versione modificata del flusso di lavoro Feature Branch per git. Nel tuo caso, a causa del modo in cui funziona TFS, il tuo ramo principale funge da area di attesa per le funzionalità fino a quando non sono pronti per un rilascio e quindi scegli e scegli quelli che desideri nel tuo rilascio. Con git e il flusso del ramo della funzione, hai due opzioni comuni per la gestione di questo:
A) Gli sviluppatori si diramano dal "master" (essenzialmente il ramo di rilascio) e sviluppano tutte le funzionalità nel proprio ramo sulle proprie macchine locali. Questi rami restano nelle loro macchine locali fino al momento in cui è necessario rilasciare una versione e quindi vengono uniti in master come desiderato per un rilascio.
B) Se stai usando un repository git "master", gli sviluppatori si diramano dal master ma invece di mantenere le modifiche locali fino al momento del rilascio, gli sviluppatori potrebbero spingere i loro rami su quel repository al completamento della funzione e quindi essere uniti quando si pianifica un rilascio. L'unico svantaggio di questo particolare approccio è che i tuoi sviluppatori dovranno eseguire sia la gestione delle diramazioni locali che remote, niente di complicato ma dal momento che le ramificazioni in git sono dei puntatori, quando stai "chiudendo" (cancellando) un puntatore di ramo, i tuoi sviluppatori avranno bisogno per farlo sui loro computer locali e qualcuno dovrà farlo sul master repository.
In entrambi i casi, non è necessario il cherry picking.
E se tu o i tuoi sviluppatori siete nuovi a git raccomando vivamente il video Git for Ages 4 an Up su Youtube. È un ottimo primer per come funziona git e come modella i rami e cambia set.
Modifica:
Come nota a parte, vedrai molti riferimenti al ramo "master" in git (e allo stesso modo di origine quando parli di repository remoti). Queste sono solo convenzioni standard. Se vuoi che il tuo ramo master sia denominato Release, puoi farlo senza problemi, dovrai solo fare le sostituzioni mentali leggendo esempi e documentazione.