合併後如何重新綁定？

Question

我們有事件的這樣一個順序：

1. 創建分支A，並添加一些提交給它
2. 時間的推移，上百的提交加入到掌握
3. 主合併到
4. 時間流逝，也許另外50個提交添加到主

是否有可能將步驟3中的合併變成rebase？如果沒有別的，它會使即將進行的合併更簡單，因爲將會看到更少的歷史。

我們還沒有啓用rerere。

Answer 1

考慮下面的Git圖：

A...C...D...F 
^  ^^master 
\  \ 
    G...H...I...J 
      ^feature 

的...的意思是 「大量的提交」。

假設我們本質上想要rebase，即在feature的歷史記錄中進行提交，但不在master的歷史記錄中進行提交，並將它們改爲master中提交的線性序列。這讓我們感到困惑，因爲我們在提交I時將主合併到了功能中。如果我們嘗試重新綁定，Git會因爲嘗試應用在主控制器上並且發現衝突的C。

我們可以通過從feature中獲取實際更改並將它們打包爲新提交來解決此問題。 這裏有一個辦法做到這一點只用很基本的Git命令：

(1) git checkout feature 
(2) git merge master 
(3) git reset A 
(4) git add -A # This stages all working copy changes 
(5) git commit -m "Every change between A and J" 

在步驟（2）中，feature分公司有兩個master和J所有更改。 經過步驟（3）後，HEAD指向A，但我們的工作副本的所有更改均爲master和J，步驟（4）和（5）階段並提交這些更改。

在這一點上我們的圖形看起來像這樣

A...C...D...F 
^   ^master 
\ 
    J' 
^feature 

注意J'包含A...F一切。現在我們做

git rebase master 

的Git愉快地應用於作爲一個新的變化J'提交J''，但添加的唯一變化是那些G...J因爲其他的變化都已經掌握。所以現在我們有

A...F<--J'' 
master^ ^feature 

與所有壓扁成犯J''我們feature分支的變化。 此時，您可以重置爲F，如果需要，可以更細化地重新應用J''中的更改（即使使用git add --patch）。

---

另一種方式基本上做同樣的事情是read-tree在this other answer

git checkout master 
git read-tree -u -m feature 

---

另一種方式做同樣的事情，從this answer被盜解釋，是

git diff master > feature.patch 
git checkout master 
patch -p1 < feature.patch