Faccio parte di un team che è recentemente passato da un repository SVN a un repository Git e che ha iniziato a utilizzare GitFlow.
A quanto ho capito, questo significa che in un mondo perfetto, il numero minimo di rami Git può essere solo di due: padroneggiare e sviluppare. In pratica, ce ne saranno di più, tenendo conto dei rami di rilascio e di argomento, ma l'obiettivo fondamentale è quello di semplificare il processo e di fondere sempre i rami verso lo Sviluppo e quindi il Master. Per tutti i lavori in corso, va bene.
La mia domanda deriva dal nostro precedente modo SVN di fare le cose. Oltre al ramo "Trunk" (ora "Develop"), abbiamo avuto una serie di filiali one-of per le versioni particolari. Questi sono stati tutti convertiti come parte del processo di conversione git, in modo che il nostro repository git assomigli a questo:
L'hotfix / , release / e topic / * branches Ho un buon senso di cosa fare. Ma che dire di tutti gli altri rami storici? Le nostre convenzioni SVN precedenti significavano che tutto ciò che facevamo in un ramo di rilascio del cliente era anche fatto nel trunk, quindi nessuno di questi rami ha un codice univoco non già in sviluppo, quindi non c'è bisogno di unirli mai di nuovo in sviluppare del tutto.
Questi rami possono essere taggati (alla testa attuale) e quindi cancellati? (Forse sto fraintendendo il punto / l'uso di tag e / o GitFlow stesso) O il nostro repository è destinato ad avere sempre questi rami legacy, a patto che siamo interessati a mantenere la cronologia?