git branch -m ha effetti collaterali per altri sviluppatori?

Question

Abbiamo already learned how to switch which branch points to what utilizzando git branch -m. Se lo faccio, renderà la vita difficile alle altre persone che estraggono dal mio deposito?

dire fare un sacco di roba su un ramo topic1 e poi fare un

git branch -m master old_master 
git branch -m topic1 master 
git push origin master 

e poi qualcun altro tira master dal mio repository remoto, cosa faranno avere a che fare per fare il punto di tutto per il posto giusto? Devo dire a tutti di ripetere i miei passi?

Questo è simile al problema di reimpostare i commit dopo averli spinti e lasciando gli altri sviluppatori con oggetti pendenti?

Answer 1

Non sono esattamente sicuro di come sia il vostro repository ma ecco lo scenario peggiore.

Supponiamo che il vostro repository origin assomiglia a questo

 
origin: 
o---o---A---B---C master 

E repository locale assomiglia a questo,

 
JimPuls: 
o---o---A---B---C master, origin/master 
     \ 
      D---E---F topic1 

Poi, dopo che il ramo rinomina repository locale si presenta così:

 
JimPuls: 
o---o---A---B---C old_master, origin/master 
     \ 
      D---E---F master 

Ora, quando si preme master a origin che sarà un aggiornamento non veloce. Dopo la spinta, il repository origin sarà simile a questa:

 
origin: 
o---o---A...B...C (B & C are orphaned commits) 
     \ 
      D---E---F master 

Questo può essere crudele con i tuoi amici che possono aver fatto impegna in cima C. Per esempio, se di Sally stava lavorando con voi il suo repository può apparire come segue:

 
Sally: 
o---o---A---B---C origin/master 
       \ 
        G---H---I master 

Ora, se fate la vostra spinta non fast-forward e Sally fa un fetch suo repository sarà simile a questa:

 
Sally: 
      D---E---F origin/master 
     /
o---o---A---B---C 
       \ 
        G---H---I master 

Ora Sally deve capire come riportare il lavoro (G, H, I) nel repository.Se esegue semplicemente un'unione con origin/master, le modifiche in B e C torneranno nel repository (oops!). Invece, lei dovrà cherry-pick o rebase il suo G-H-I cambia su origin/master.

È fantastico che Git ti consenta di farlo, ma è un po 'come chiedere dei problemi. Speri davvero che Sally noti la situazione. Questo è il motivo per cui dovresti avvisare tutti gli altri contributori quando fai questo in modo che possano gestire il cambiamento in modo appropriato.

NOTA: quanto sopra è uno scenario peggiore. Se la filiale topic1 è partita da master in C, la modifica è un avanzamento rapido e non ci sono problemi.

Answer 2

Fondamentalmente le operazioni sono le stesse:

# git checkout master 
# git reset --hard topic1 
# git push origin master 

e avranno esattamente questo effetto: Tutti gli altri avranno il ramo topic1 (prende il nome master per loro, però) e la sua discendenza fino al punto dove master e topic1 prima divergevano. Il vecchio ramo master si trova nei repository e in futuro verrà sottoposto a garbage collection perché nulla lo indica più.

Se topic1 è una diramazione che è originata dall'attuale HEAD di master qui starai bene. Altrimenti, entrerai nella situazione della "cronologia della riscrittura" che può causare un pasticcio, ad es. i tuoi tag. Hai bisogno di riflettere attentamente su ciò che stai davvero cercando di ottenere. Forse un semplice git merge ti servirà meglio?