Seguendo git-flow come dovreste gestire un hotfix di una versione precedente?

Se provi a seguire il modello di ramificazione git-flow, documentato qui e con gli strumenti qui , come dovresti gestire questa situazione:

Hai realizzato una versione 1.0 e una versione 2.0. Quindi è necessario creare un hotfix per 1.0. Si crea un ramo di aggiornamento rapido dal tag 1.0 e si implementa qui la correzione. Ma allora cosa?

Normalmente dovresti unirti a master e inserire un tag di rilascio 1.1 lì. Ma non puoi unire 1.1 a un punto dopo 2.0 su master.

Immagino che potresti mettere il tag di rilascio sul ramo dell'hotfix, ma ciò creerebbe un ramo permanente accanto al master che conterrebbe un tag di rilascio. È questo il modo giusto?

Sembra che ci sia il concetto di un ramo di "supporto" in git flow. Viene utilizzato per aggiungere un hotfix a una versione precedente.

Questo thread ha più informazioni , con questi esempi:

git checkout 6.0
git checkout -b support/6.x
git checkout -b hotfix/6.0.1

... fai la tua correzione, quindi:

git checkout support/6.x
git merge hotfix/6.0.1
git branch -d hotfix/6.0.1
git tag 6.0.1

o usando i git flowcomandi

git flow support start 6.x 6.0
git flow hotfix start 6.0.1 support/6.x

... apporta le modifiche quindi:

git flow hotfix finish 6.0.1

Domanda interessante! Il flusso collegato presuppone che il master possa tenere traccia della produzione. Funziona solo se le versioni di produzione sono in rigoroso aumento. Ciò è generalmente vero per un sito Web che ha una sola versione di produzione.

Se devi mantenere più versioni di produzione, un ramo per monitorare la produzione non è sufficiente. Una soluzione è non utilizzare il master per tenere traccia della produzione. Invece, utilizzare rami come release1, release2ecc

In questo approccio, potresti non aver nemmeno bisogno di un hotfix branch. Potresti risolvere il problema sul release1ramo. Quando la correzione è abbastanza buona, crea un release1.1tag sul release1ramo.

git-flow presume che tu stia supportando solo una riga di rilascio alla volta, opportunamente tracciata dal master. Se ne stai mantenendo più di 1, dovrai modificare il processo git-flow per avere più tracker delle tue versioni separate che stai supportando (master-1, master-2). È possibile continuare a utilizzare il master per tenere traccia della riga di rilascio più recente, in aggiunta o al posto di un tracker specifico per la riga di rilascio più recente (master al posto di master-2).

Sfortunatamente, qualsiasi strumento git-flow che potresti utilizzare dovrà probabilmente essere modificato, ma si spera che tu abbia abbastanza familiarità con il processo git-flow per gestire questo caso specifico direttamente con i comandi git.

git config --add gitflow.multi-hotfix true Questo comando sembra funzionare per me!