Qual è la differenza tra "rinominare git branch in master" e "merging branch in master con l'opzione -s ours"?

Question

Abbiamo portato su repo CVS vecchio di 9 anni a Git usando cvs2git. Nel periodo in cui siamo finiti a lasciare il tronco (nel mondo cvs) dietro e fatto uno dei rami come produzione (prod_br). Non molte persone come questo, ma il passato è passato :)

Ora che abbiamo convertito a Git abbiamo due opzioni (in base alle risposte precedenti su StackOverflow):

1. Spostare cambiamenti nel ramo di produzione (prod_br) per padroneggiare e ricominciare con il nuovo master e continuare. (git checkout prod_br, git merge -s ours master, git checkout master, git merge prod_br)

2. Rinomina prod_br come master e continua da qui. (Git branch -m prod_br maestro)

Qual è la differenza tra questi due approcci? Qualsiasi pro/contro.

Abbiamo anche una terza opzione in mente: mantieni il master attuale così com'è e continua a costruire in cima a prod_br. Questo è tipo di vivere su un repo con un master che non sarebbe mai usato in futuro. Questo è anche come se prod_br fosse "il nostro maestro logico". C'è qualche svantaggio di avere un repo con un master che non verrebbe mai usato come master?

Qualsiasi aiuto/guida è apprezzato.

Answer 1

Qual è la differenza tra i due precedenti metodi?

Il primo approccio probabilmente creerebbe un merge-commit che sarebbe buono dal punto di vista storico, come sarà chiaro quando si è verificato il passaggio al master.

Quando si esegue il merge torna da padroneggiare, come best practice per garantire l'unione-commit si consiglia di utilizzare il --no-ff (senza fast-forward) Opzione:

git merge --no-ff prod_br 

Per quanto riguarda il secondo l'opzione, rinominando il ramo funzionerebbe ma non si autocorreggerebbe come il merge-commit e, cosa più importante, sarebbe perché è necessario forzare la modifica che potrebbe disturbare altri utenti. (avrebbero bisogno di fare un rebase o altra operazione per ottenere la loro versione del ramo per essere raggiungibile nuovo con il telecomando)

C'è qualche svantaggio di avere un pronti contro termine con un maestro che avrebbe mai essere usato come un maestro?

Non proprio una vera svantaggio ma in Git la convenzione è quello di avere il vostro principale, ramo di produzione sia master. Quindi se usi master il tuo repository sembrerà più standard per gli altri che aderiranno al progetto. Inoltre, quando clonano di default verranno messi direttamente sul master (salvo l'opzione --branch), quindi sarà un passo in meno da ricordare (passando al ramo di produzione ad hoc).

IMO un'operazione importante come questa richiede un self-documenting merge-commit quindi Penso che l'opzione 1 sia l'approccio migliore.