爲什麼使用git rebase -i重新排序提交不會搞砸歷史？

Question

據我所知，提交文件的快照所以如果我執行更改A然後更改B，更改B的提交文件已包含更改A中的更改，不會重新排序更改A冗餘嗎？

Answer 1

也就是說，其實是一個非常好的問題，因爲提交是快照。

底墊原因的工作原理是因爲底墊實際上是重複git cherry-pick（有位在前面包裹的找出該選擇什麼樣的，多在年底移動分支標籤），並git cherry-pick作品轉動承諾變更集。

假設，例如，你有提交的序列：

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

變基topic到mainline我們需要（1）發現，上topic的提交，但不mainline（這是C，B ，並沿着第一行A，結束於標記爲*的提交），然後（2）將它們複製到新的提交中，我們將在mainline的提示下添加新提交。

再次基於第一發現三個後*提交，並將它們放入一個（反向下令：A，B，C）列表（也忽略了合併默認的提交，但這裏沒有合併）。然後它爲每個提交做一個櫻桃選擇。

爲了挑選A，Git比較A而不是*。這將兩個快照轉換爲變更集。混帳然後應用最尖端提交的mainline的更改，使一個新的承諾，讓我們稱之爲A'，在一個匿名的分支：

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

要櫻桃採摘B，Git的diff文件B對A。將這些更改應用於A'會產生另一個提交B'。重複C獲得C'：

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

最後，從Git的剝離C的topic標籤路程，它指向C'代替。鏈老被放棄（雖然你仍然可以通過reflogs找到它，rebase副本C的ID，以特殊的名字ORIG_HEAD以及）：

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

現在的重訂完成。

請注意，如果需要，每個副本都使用git的合併機制完成（如果diffs不適用於乾淨地）。每個人都可能導致合併衝突，需要重組停止並獲得您的幫助。 （或者，更糟糕的是，你可能會錯誤合併，儘管這些在實踐中很少見。）

當然，如果您重新訂購提交（通過在交互式轉化中移動pick行），我們只需更改我們選擇的順序並應用每個提交。櫻桃採摘操作仍然以相同的方式工作：比較挑選的提交與其父母（C與B,A與*,B與A）。