Flusso di lavoro appropriato per Git per più rilasci attivi durante la gestione degli hotfix

27

Sto provando a scegliere un flusso di lavoro Git più appropriato per il nostro prodotto. Ecco i parametri:

  • Facciamo un paio di pubblicazioni importanti all'anno, diciamo 10 al massimo
  • Abbiamo più versioni del nostro prodotto attive contemporaneamente (alcune persone sono su v10.1, altre su v11.2, ecc.)
  • Dobbiamo essere in grado di lavorare su più versioni contemporaneamente (quindi potremmo lavorare sulla versione 12.1, ma mentre arriviamo alla fine del rilascio iniziamo a lavorare sulla v12.2 contemporaneamente)
  • Dobbiamo essere in grado di rilasciare aggiornamenti rapidi quando vengono rilevati errori critici

Finora, ecco il modo in cui penso possa funzionare:

  • È utilizzato un unico repository remoto
  • Crea il ramo 12.1 dal master
  • Crea feature branch basate su 12.1, esegui il commit e unisci di nuovo in 12.1, premi
  • Una volta che abbiamo bisogno di iniziare a lavorare sulla versione futura, crea un nuovo ramo 12.2 basato su 12.1
  • Da quel momento in poi, quando lavori su una funzionalità per 12.1, crea una diramazione da 12.1, commuta le modifiche e unisci in entrambe le versioni 12.1 e 12.2, premi
  • Se stai lavorando su una funzione per 12.2, crea una diramazione dalla 12.2, commuta le modifiche e unisci solo nella 12.2, premi
  • Una volta completata la versione 12.1, unirla in master e tag ramo master con 12.1
  • Se è necessario un aggiornamento rapido, creare un ramo di aggiornamento rapido dal ramo di rilascio più vecchio che lo richiede, eseguire il commit delle modifiche e unire nuovamente tutti i rami di rilascio per quella release e le versioni future che potrebbero essere interessate; se l'ultimo ramo di rilascio stabile è stato interessato, uniscilo in master.

Ho qualche dubbio:

  • Non sono sicuro che unire gli hotfix delle vecchie filiali in nuove filiali sarà un processo semplice, specialmente se ci sono state molte modifiche sovrapposte; Sarebbe più intelligente eseguire 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 tenere molto vivo il ramo di rilascio, una volta che il rilascio viene fuso in master, taggato e rimosso. Il mio problema è che non ho una buona idea di come gestire lo stato del rilascio se tutto quello che ho sono tag in master, sembra più facile l'aggiornamento rapido in un ramo e quindi ho un rilascio che posso sempre tornare a che ha l'ultimo aggiornamento rapido (posso anche taggare gli hotfix nella versione). Non sono sicuro che ci sia un modo per tornare indietro nel master e in qualche modo avere una copia della versione con gli hotfix applicati e aggiornare quel tag.

I commenti sono apprezzati su cose che potrei aver trascurato o modi migliori per realizzare le cose, dati i requisiti che ho specificato.

    
posta Rocket04 16.01.2015 - 17:13
fonte

3 risposte

8

Sembra che si stia ramificando su tutte le versioni principali (12.0.0), quindi con possibili aggiornamenti minori per ciascuna (12.1.0) e hot fix (12.2.1). Corretto?

Non c'è una ragione specifica per cui non è possibile mantenere vivi i rami di rilascio in GitFlow dopo che è stato rilasciato un rilascio, a parte il fatto che coordinare le modifiche tra più rami divergenti per un lungo periodo è difficile con qualsiasi modello. Suppongo che GitFlow sia stato anche modellato di più per i prodotti che mantengono una singola versione live durante lo sviluppo del prossimo.

Mi assocerei a GitFlow e apporterò alcuni emendamenti;

Salta il ramo principale. Finora non ne ho fatto uso pratico e perderebbe la sua linearità nel modo in cui lavori. Mantenere lo sviluppo sulla prossima major release in sviluppo. Se decidi di mantenere il master, non mettere tag di rilascio sul master, metterli sull'ultimo commit sul ramo di rilascio che ha prodotto il file binario che stai spedendo.

Non buttare via i rami di rilascio dopo averli riuniti per svilupparsi. Invece tenerli in giro per la prossima versione secondaria e possibili correzioni rapide. Se mai smettessi di supportare una versione, suppongo che sia corretto cancellarli. Potresti denominare i rami di rilascio dopo il loro componente principale, release / 12, e quindi creare rami di sotto-rilascio, rilasciare / 12.1, rilasciare / 12.2 fuori da esso. Non ho dovuto preoccuparmi troppo di questo livello di parallelismo, ma è probabilmente quello che proverei. In questo caso puoi pensare a ciascun ramo di release principale come a un proprio ambiente sub-GitFlow.

Se devi lavorare in parallelo su funzionalità per diverse future versioni principali contemporaneamente, forse devi mantenere il successivo (13) sullo sviluppo e qualsiasi cosa per le versioni successive (14, 15) su ulteriori "sviluppi" N "rami. Sembra molto difficile da mantenere in generale, ma sarebbe possibile.

    
risposta data 28.02.2016 - 03:07
fonte
3

Sembra che una possibile soluzione per il tuo problema principale ( «Dobbiamo essere in grado di lavorare su più versioni contemporaneamente [...]» ) sta facendo un git worktree add <path> [<branch>]

A git repository can support multiple working trees, allowing you to check out more than one branch at a time.
With git worktree add, a new working tree is associated with the repository.

This new working tree is called a "linked working tree" as opposed to the "main working tree" prepared by "git init" or "git clone".
A repository has one main working tree (if it's not a bare repository) and zero or more linked working trees.

Vedi questa risposta SO per un'introduzione dettagliata su git worktree .

    
risposta data 27.02.2016 - 13:24
fonte
1

Hai detto che hai familiarità con gitflow. Suggerisco di aggiungerlo per il tuo scenario. Dovrai creare filiali dal tuo ramo di sviluppo per supportare versioni precedenti. Queste versioni precedenti dovranno anche avere i propri rami di rilascio / master e rami di aggiornamento rapido. Dovrai unire periodicamente i tuoi rami di supporto ai nuovi rami di supporto e al ramo di sviluppo.

Man mano che lo sviluppo delle versioni principali diverge, questo diventerà sempre più difficile. Non c'è un proiettile d'argento per questo. A volte sarà più facile apportare modifiche manualmente. Il costo di mantenere le versioni precedenti aumenterà, e ad un certo punto non ne valuterà più.

Dipende tutto da che tipo di modifiche stai apportando nelle tue versioni precedenti. Se solo si corregge, questo è relativamente facile da unire. Se provi ad aggiungere nuove funzionalità, sarà difficile.

    
risposta data 17.01.2015 - 14:04
fonte

Leggi altre domande sui tag