Cosa fare con i rami storici SVN dopo il passaggio a GitFlow?

5

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?

    
posta Sable Dreamer 08.08.2018 - 21:12
fonte

1 risposta

6

Se mantenere i rami intorno o convertirli in tag è in gran parte una questione di preferenze personali.

Git ha due tipi di tag: tag leggeri che sono solo un riferimento a un commit e tag annotati. I tag annotati sono oggetti git che possono includere un messaggio e / o una firma, come un commit.

I rami sono fondamentalmente uguali ai tag leggeri, tranne che vengono spostati automaticamente quando si aggiunge un commit a un ramo. (Puoi spostare manualmente i riferimenti di ramo con git-reset.)

Se non aggiungerai mai commit a questi rami storici, convertirli in tag sarebbe idiomatico:

  • assicurati che il ramo sia fuso in master.
  • crea un nuovo tag
  • elimina il vecchio ramo

I nomi dei tag e i nomi dei rami vivono in diversi spazi dei nomi ( refs/tags e refs/heads ) in modo da poter mantenere i nomi esistenti per il tag.

    
risposta data 08.08.2018 - 21:38
fonte

Leggi altre domande sui tag