Gitflow con più rami master

Question

Mentre questo è simile al thread Git-flow and master with multiple parallel release-branches e What's best way to work with git on multiple master branch?, non è del tutto identico ... Ho trovato questo è piuttosto simile: Multiple projects with same GIT master, ma voglio discutere il mio caso d'uso specifico ...

La società per cui lavoro è in procinto di definire politiche e procedure per il nostro flusso di lavoro Git. Vogliamo utilizzare il modello "Gitflow" come descritto nell'articolo http://nvie.com/posts/a-successful-git-branching-model/ o https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow e viene comunemente utilizzato in molte discussioni sull'argomento.

Abbiamo un caso d'uso, tuttavia, con un requisito per il quale non riesco a trovare una soluzione documentata. Cosa succede se il tuo progetto viene utilizzato per produrre più di un prodotto finale? Il ramo principale non può quindi rappresentare i "punti di rilascio" come se si trattasse di un singolo prodotto. Sembra che forse sono necessari rami alternativi dal maestro? Quindi più rami paralleli di rilascio?

Ad esempio, cosa accade se il progetto funge da dorsale o motore per qualcosa che può avere skin, sapori o varianti diversi ma si desidera che ciascuno dei prodotti finali risultanti completi sia archiviato in un unico repository?

Nel mio caso particolare, ho un programma che gira su un server Linux, ma è anche distribuito come applicazione Windows locale. In queste versioni differenti, ci sono grossi pezzi del progetto che possono o non possono essere inclusi in una o nelle altre versioni. Ad esempio, ci sono librerie sul server che non devono essere incluse se il repository era solo per il server, ma che deve essere incluso per la distribuzione locale dove altrimenti non esisterebbero. Voglio portare gli aggiornamenti al repository sul server in specifici punti di rilascio, ma omettere questi pezzi che non ci appartengono.

Dal ramo master, dovrei creare un ramo "Server Release" e "Local Release"?

Dove dovrebbe uscire il ramo di sviluppo (e le sue caratteristiche)? Non voglio più rami di sviluppo, ciascuno proveniente dalla sua stessa versione, poiché gli sviluppi del codice sono infatti del 99% applicabili a entrambi. Devo unire un singolo ramo dev in uno e poi nell'altro rilascio?

Answer 1

Se il 99% del codice è condiviso tra i due prodotti, è possibile condividere facilmente lo stesso repository. Puoi avere un singolo ramo di rilascio/sviluppo/master purché i due prodotti si trovino sullo stesso ciclo di rilascio, ad esempio, la versione 2.0 viene spedita nello stesso momento.

Dal ramo principale, dovrei creare un ramo "Server Release" e "Local Release"?

In gitflow in realtà si rilasciano i rilasci da sviluppare! Ma nel caso in cui siano in cicli di rilascio diversi, non c'è nulla che ti impedisca di creare un ramo di rilascio per prodotto. Quindi sei libero di unire i rami di rilascio allo sviluppo e ai rami master quando vengono eseguiti nel loro tempo. L'unica cosa qui è che probabilmente avrai bisogno di due diversi tipi di tag sul ramo master in modo che tu possa vedere dove ogni prodotto si trova nel suo ciclo di rilascio. O per mantenere i tag nello stesso formato, potresti avere due rami principali (uno per prodotto), che vengono uniti rispettivamente quando una funzionalità viene completata per il rispettivo prodotto.