Consigli di ramificazione di TFS

Sembra "scenario 2: branch for release" come descritto da guide Microsoft .

Probabilmente è la strategia di ramificazione più comunemente usata quando si utilizza TFS, si ha una diramazione principale da cui si crea un ramo Dev per lo sviluppo, quando si legge la fusione, si fondono su Main, si eseguono alcuni test e poi rilascia dalla sezione principale o, più comunemente, porta il Main su un ramo di rilascio in modo da poter apportare modifiche a una singola release senza doversi preoccupare di ulteriori aggiornamenti che sono stati uniti a Main per intromettersi.

Alcune persone non eseguono mai correzioni di bug direttamente sul ramo di produzione, si ramificano da esso, risolvono i bug e li uniscono quando sono stati testati e verificati. Rende le cose più facili se decidi di non andare con le correzioni dei bug, o devi ripristinarle in un secondo momento, poiché ogni versione di bug fix sarà una singola revisione "unione" sul ramo di rilascio piuttosto che un mucchio di commit.

Quindi, in sintesi: vorrei andare con 3 rami, uno per lo sviluppo, uno per il controllo qualità (che è anche la linea principale) e un altro per le pubblicazioni. puoi taggare ogni revisione del rilascio se sai di non dover mantenere le vecchie versioni, ma se lo fai, allora quel ramo Release dovrebbe essere un ramo di rilascio per versione, o versione principale, del tuo prodotto.

Con git e sistemi simili, tendi a vedere più di una feature o di una strategia di team branch poiché la fusione è molto più semplice che su TFS. Con qualcosa come svn, tendi a vedere entrambi i tipi.