Git pull.rebase questa è un'operazione potenzialmente pericolosa

Question

Nella documentazione git-config all'indirizzo pull.rebase:

pull.rebase

Quando vera, REBASE rami in cima al ramo recuperata, invece di unire il ramo predefinito dal remoto predefinito quando viene eseguito "git pull" su . Vedere "branch..rebase" per l'impostazione su base per ramo.

NOTA: questa è un'operazione potenzialmente pericolosa; non usarlo a meno che non si sia a capire le implicazioni (vedere git-rebase (1) per i dettagli).

Qualcuno potrebbe descrivere in dettaglio cosa significa "NOTE: this is a possibly dangerous operation; do not use it unless you understand the implications (see git-rebase(1) for details)"?

Answer 1

Diciamo che avete questi repository Git:

• tuo repo privata, seduto sul tuo computer di lavoro;
• il tuo deposito pubblico, you, ospitato da qualche parte;
• un repository principale, origin, che è l'albero di sviluppo principale.

Stai lavorando su qualcosa e hai fatto due commit A e B. Li hai pubblicati al tuo repo pubblico. Nello stesso tempo, ha un altro origin commettere Z.

 /-A-B master, you/master 
o-o-o 
    \-Z origin/master 

Ora diciamo che un collega ha bisogno dei vostri due commit per iniziare una nuova funzionalità. Tira il tuo ramo dal tuo repo pubblico e fa qualche commit su quello.

  /-C-D-E colleague/master 
    /-A-B master, you/master 
o-o-o 
    \-Z origin/master 

ora si desidera aggiungere la due, completamente testato, commette in cima origin/master. Recupera da origin e crea un rebase (che equivale a git pull --rebase o git pull con l'opzione di opzione pull.rebase). Ciò crea due commit nuovi. Li spinge al tuo repo pubblico e al origin. Per complicare ulteriormente le cose, diciamo che un nuovo commit F viene inviato a origin dopo.

 /-A-B-C-D-E colleague/master 
o-o-o 
    \-Z-A'-B'-F master, you/master, origin/master 

Ora il problema è che il vostro collega ha qualche lavoro basato su due "deprecato" si impegna, e per evitare ulteriori complicazioni (conflitti quando si uniscono, rovinare la storia) deve rebase suo ramo in cima B'(diciamo che non vuole F). Devi dirglielo, altrimenti forse non si accorgerà di quello che hai fatto.

  /-C-D-E colleague/master 
o-o-o-Z-A'-B'-F master, you/master, origin/master 

Se non lo hai detto, poi sarebbe fondere la sua filiale di nuovo in origine e la storia sarebbe simile a questa:

 /-A-B-C-D-E 
o-o-o   \ 
    \-Z-A'-B'-F-M colleague/master, origin/master 

Lei ha il doppio della A e B si impegna, anche se con nomi diversi. La cronologia diventa più difficile da leggere, e tu esegui conflitti di fusione. E ricorda questo esempio è abbastanza semplice. Se ci sono decine di persone che lavorano al progetto e origin si sta muovendo velocemente, la cronologia diventerà presto un casino completo.

Se è solo un collega, probabilmente sta bene. Ma se non sai esattamente chi ti ha strappato, non puoi sapere chi devi avvisare. È particolarmente vero nello sviluppo open source.

La regola principale è: non rebase i commit che hai già pubblicato. Se A e B fossero solo nel tuo repository privato, la rebasing è soddisfacente ed è probabilmente la cosa migliore da fare, perché rende la storia più semplice e significativa. Una storia divergente è significativa solo quando il ramo ha una buona ragione per esistere (ad esempio un ramo di una caratteristica).

Answer 2

Rebase è un comando utilizzato per riscrivere la cronologia dei commit e la riscrittura dei commit causa la modifica degli ID SHA. Rifondando i propri commit privati ​​che nessun altro ha basato il proprio lavoro (cioè commetti sopra) va bene.

Tuttavia, si esegue nei guai quando si REBASE condiviso storia pubblica, perché altre persone che hanno la vecchia storia che si Ribasato sono costretti a sincronizzare o ripristinare i loro commit sulla parte superiore della nuova storia (che può potenzialmente essere un difficile processo), o cercare di risolvere la vecchia storia con quella nuova, che produrrà sicuramente conflitti. Dal official Linux Kernel Git documentation for rebase:

rebasing (o qualunque altra forma di riscrittura) un ramo che altri hanno basato il lavoro su è una cattiva idea: chiunque a valle dello stesso è costretto a correggere manualmente la loro storia.

Pertanto, non è necessario rebase commit a meno che non si sia sicuri che nessun altro condivide quei commit che si stanno ridefinendo.

Detto questo, dovresti davvero imparare a rebase però, sia interattivamente che in modo non interattivo, perché è lo strumento più potente ed efficace nell'arsenale di Git, e se non sai come usarlo, allora sei non usare Git in modo efficace.

È possibile ottenere ulteriori informazioni sulla ridefinizione dalla sezione Rewriting History dello free online Pro Git book e, naturalmente, lo official Linux Kernel Git documentation for rebase è eccellente.

Answer 3

Vale la pena di ricordare che un "cambiamento male" da un "evil merge" può essere perso silenziosamente mentre rebasing un "merge male" che contiene un "cambiamento del male", che non sia in conflitto con altri commit.