合並后如何變基？

Question

我們有一系列這樣的事件：

1. 創建分支A，並為其添加一些提交
2. 時間過去了，數百次提交添加到master
3. 大師合並為A
4. 時間過去了，可能還有另外50個提交添加到master

是否可以將步驟3中的合並轉換為rebase？ 如果不出意外，它會使即將發生的合並變得更簡單，因為可以看到更少的歷史記錄。

我們沒有啟用rerere。

Answer 1

考慮以下Git圖：

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

......意味着“很多提交”。

假設我們想要實質上重新定義，即在特征歷史中提交而不是在主歷史中進行提交，並將它們改為主數據提交的線性序列。 這讓我們在提交I中將master合並到feature中這一事實而感到困惑。 如果我們試圖改變，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的更改，因為其他更改已經在master中。 所以現在我們有了

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

將我們的feature分支中的所有更改壓縮為提交J'' 。 此時，如果需要，您可以重置為F並以更精細的方式重新應用J''中的更改（即使使用git add --patch ）。

---

另一種基本相同的方法是使用read-tree如另一個答案所述

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

---

從這個答案中竊取的另一種做同樣事情的方法是

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