Sto cercando di scegliere un flusso di lavoro Git più appropriato per il nostro prodotto. Ecco i parametri:
- Facciamo alcune pubblicazioni importanti all'anno, diciamo al massimo 10
- Abbiamo più versioni del nostro prodotto attive contemporaneamente (alcune persone sono su v10.1, alcune su v11.2, ecc.)
- Dobbiamo essere in grado di lavorare su più versioni contemporaneamente (quindi potremmo lavorare su v12.1, ma quando arriviamo alla fine della versione iniziamo a lavorare su v12.2 contemporaneamente)
- Dobbiamo essere in grado di aggiornare i rilasci quando vengono rilevati bug critici
Finora, ecco come penso che potrebbe funzionare:
- Viene utilizzato un singolo repository remoto
- Crea il ramo 12.1 dal master
- Crea rami funzione basati su 12.1, esegui il commit e ricollegali in 12.1, premi
- Una volta che avremo bisogno di iniziare a lavorare su versioni future, creare un nuovo ramo 12.2 basato su 12.1
- Da quel momento in poi, quando si lavora su una funzione per 12.1, creare una succursale dalla 12.1, eseguire il commit delle modifiche ed unire in 12.1 e 12.2, premere
- Se si lavora su una funzione per 12.2, creare un ramo da 12.2, eseguire il commit delle modifiche e unire solo in 12.2, premere
- Una volta completata la versione 12.1, uniscilo nel master e tagga il ramo master con 12.1
- Se è necessario un aggiornamento rapido, creare un ramo di aggiornamento rapido dal ramo di rilascio più vecchio che ne ha bisogno, eseguire il commit delle modifiche e ricollegarlo a tutti i rami di rilascio per quella versione e le versioni future che potrebbero essere interessate; se è stato interessato l'ultimo ramo di versione stabile, uniscilo nel master.
Ho alcune preoccupazioni:
- Non sono sicuro che la fusione di hotfix da vecchi rami in nuovi rami sarà un processo regolare, soprattutto se ci sono state molte modifiche sovrapposte; sarebbe più intelligente semplicemente l'aggiornamento rapido manualmente in ogni ramo nei casi in cui sembra che ci saranno conflitti
- I modelli di flusso di lavoro che ho visto sembrano non mantenere molto attivi i rami di rilascio, una volta fatto il rilascio viene unito in master, etichettato e rimosso. Il mio problema è che non ho una buona idea su come gestire lo stato della versione se tutto ciò che ho sono tag nel master, sembra più facile effettuare l'aggiornamento rapido in un ramo e quindi ho una versione in cui posso sempre tornare indietro con l'ultimo aggiornamento rapido (posso anche contrassegnare gli aggiornamenti rapidi nella versione). Non sono sicuro che ci sia un modo per tornare indietro in master e in qualche modo avere una copia della versione con hotfix applicati e aggiornare quel tag.
I commenti sono apprezzati su cose che potrei aver trascurato o sui modi migliori per realizzare le cose, dati i requisiti che ho specificato.
4
nvie.com/posts/a-successful-git-branching-model
—
Wilbert
Sono a conoscenza di git-flow, ma non vedo come risolva il problema lavorando su più versioni simultanee. Sembra che i rami di rilascio non siano nemmeno fatti per fare alcun lavoro, principalmente per fare pulizia e quindi unire e taggare. Cosa devo fare quando ho un hotfix che interessa 4 diverse versioni di rilascio? Immagino di poter effettuare il checkout di una versione taggata dal master, ma una volta che ho apportato delle correzioni, come potrei rielaborare qualsiasi correzione che ho apportato al master per quella particolare versione. Sembra che sarebbe piuttosto difficile.
—
Rocket04,
Se è necessario correggere a caldo più versioni con la stessa correzione, è probabile che sia necessario correggere prima la versione più vecchia e unirla a quella più recente, adattandosi per adattarsi a ciascuna versione. Se lavori di nuovo in vecchio, rischi di eliminare le dipendenze dalle versioni successive, il che complicherebbe le cose.
—
axl
E come menziono nella mia risposta proposta, il ramo master non funziona così bene con più versioni live, quindi a meno che tu non ne abbia davvero bisogno per qualche motivo, ti consiglierei di non usarlo.
—
axl