我想问你两种方法之间有什么区别。
起始情况是：
master branch
|
E F - test branch
| |
D C
| /
B
|
A
第一种方法：
git checkout test
git merge master
git rebase -i master
git checkout master
git merge test
第二种方法：
git checkout test
git rebase -i master
git checkout master
git merge test
我想要做的是将C和F压缩成一个提交，然后在master上将其重新绑定，以便它显示为master上的一个新提交。
但是，我为实验使用了第一种方法（通常使用第二种方法）并且结果很糟糕。使用第一种方法后，主人的一些变化就丢失了。
所以我的问题是有什么区别？如果我在两种方法之后得到它，那么最终图形应该如下：
master branch
|
G = C + F + old master
|
E
|
D
|
B
|
A
答案 0 :(得分：1)
有点难以说明两种方法之间的区别是什么，而不知道你在交互式rebase期间做了什么。
但是在第一种方法中，合并将向M分支添加一个新提交（让我们称之为test）。因此，合并后立即回购将如下所示：
master branch
|
| M - test branch
|/ |
E F
| |
D C
| /
B
|
A
（请注意master不变。）
现在，当你进行交互式rebase时，git意识到只有C和F（而不是合并提交，M）需要应用于master。因此，如果不对rebase文件中的命令/提交列表进行任何更改，最终会得到：
master branch
|
E --- C --- F - test branch
|
D
|
B
|
A
（再次注意master没有改变。）
在交互式rebase期间，如果您将pick更改为squash / fix以进行提交F，则会将其合并到C。所以你最终会得到：
master branch
|
E --- C+F - test branch
|
D
|
B
|
A
最后，在将test合并到master后，您最终得到：
E --- C+F - test / master branch
|
D
|
B
|
A
两种方法的区别在于第一种方法在test分支上创建合并提交，然后在test重新定位到master时消失。
答案 1 :(得分：0)
将母版合并到测试中并且没有任何意义。由于合并时已经存在测试更改。
要达到你想要的效果，你需要使用--squash
- 南瓜将你在测试中提交的所有提交压缩成一个，所以在你的历史记录中它似乎是一次提交。