Perché il riordino dei commit con git rebase -i non rovina la cronologia?

Question

Come ho capito, le istantanee sono file quindi se eseguo il cambio A e poi cambio B, cambio B il commit il file include già le modifiche nella modifica A, non riordinerebbe apportare modifiche A ridondante?

Answer 1

Questa è, in effetti, una domanda molto buona, perché commette le istantanee.

La ragione rebase funziona è perché rebase è effettivamente ripetuto git cherry-pick (con un po 'di avvolgere sul davanti per capire cosa scegliere, e più alla fine di spostare le etichette ramo) e git cherry-pick opere girando una impegnarsi in un set di modifiche.

Supponiamo per esempio di avere questa sequenza di commit:

  A--B--C <-- topic 
     /
...--o--*--o--o  <-- mainline 

Per rebase topic sul mainline abbiamo bisogno di (1) trovare i commit che sono sul topic ma non su mainline (che sono C, B e A lungo la riga superiore, che termina con il commit contrassegnato con *), quindi (2) copiarli in nuovi commit che verranno aggiunti sotto la punta di mainline.

Rebase trova primo dei tre post-* commit e li mette in un (reverse ordinato: A, B, C) Lista (si omette anche unire i commit per impostazione predefinita ma non ci sono unioni qui). Quindi esegue un cherry pick per ogni commit.

A cherry-pick A, Git diffs A contro *. Questo trasforma le due istantanee in changeset. Git quindi applica le modifiche alla punta più a commit mainline e fa un nuovo commit, chiamiamolo A', su un ramo di anonimo:

  A--B--C <-- topic 
     /
...--o--*--o--o  <-- mainline 
       \ 
       A' <-- HEAD 

Per cherry-pick B, Git diff B contro A. L'applicazione di queste modifiche a A' produce un altro commit B'. Ripetere l'operazione per C di ottenere C':

  A--B--C   <-- topic 
     /
...--o--*--o--o   <-- mainline 
       \ 
       A'-B'-C' <-- HEAD 

scorso, Git bucce l'etichetta topic lontano da C e la punta a C' invece. La vecchia catena è abbandonato (anche se è ancora possibile trovare attraverso reflogs, e rebase copia l'ID del C al nome speciale ORIG_HEAD così):

  A--B--C   [abandoned] 
     /
...--o--*--o--o   <-- mainline 
       \ 
       A'-B'-C' <-- topic 

e ora il rebase è completo.

Nota che ogni copia viene eseguita utilizzando i meccanismi di fusione di git, se necessario (se i diff non si applicano in modo pulito subito). Ognuno può provocare un conflitto di merge, richiedendo il rebase di fermarsi e ottenere aiuto da voi. (O, peggio, puoi ottenere un mis-merge, anche se questi sono rari nella pratica.)

Ovviamente, se si riordina il commit (spostando le linee pick in un rebase interattivo), si modifica solo l'ordine che selezioniamo e si applica ogni commit. Le operazioni cherry-pick funzionano ancora allo stesso modo: confronta il commit selezionato con il suo genitore (C vs B, A vs *, B vs A).