合并后如何重新绑定？

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