此问题已在此处有答案：
When do you use Git rebase instead of Git merge?（20个回答）
What's the difference between 'git merge' and 'git rebase'?（8个回答）
3天前关闭。
我正在使用branch A，它是从branch B创建的，而branch B是从master创建的。
现在master已经向前移动了，我想将master分支的更改包含到A中。How can I do that?
我在过去通过将master合并到分支A中来实现这一点。但我不确定这是否是一个好方法。
我从master那里听说了很多关于doing a rebase的东西，但不确定有什么区别，因为最终我只希望新代码在分支A中
2条答案
按热度按时间v440hwme1#
好吧，我很确定有很多类似的问题和答案涵盖了这个主题，但尽管如此。
你的历史是
master -> B -> A。看起来你想去
new-master -> new-A（不再有B）。或者换句话说，您希望工作分支
A在当前master中的任何内容之上包含您的更改。Rebase
在这种情况下，您几乎总是希望在新的master之上 rebase 您的本地更改。
假设没有冲突--因为这些冲突可能会使一个变基乍看起来更具挑战性（但有一个补救办法）--假设你向你的工作分支提交了5次。
在 rebase 之后，你的新工作分支仍然会包含5个提交-但是在最新的“master”之上，会有不同的提交SHA，因为这些SHA将被重写。
合并
相同的设置，没有冲突，你在你的分支中提交了5次。
在 merge 之后，所有这些提交将仍然存在于它们现有的SHA中-并且将有第六次提交，即所谓的“合并提交”，它将获取master的所有更改并将它们合并到您的分支中。
何时选择
由于 rebase 会在新master之上重新应用本地更改，因此它们的提交SHA也会改变。
但是，您最终会处于这样一种情况，即您最终将更改上游化要容易得多，因为您的历史看起来像
new-master -> your 5 commits -> HEAD。而 merge 不会触及那些旧的提交-但会产生像
master -> your 5 commits -> all changes between old and new master in a single merge commit -> HEAD这样的历史。这通常很难最终合并上游。
重基大量提交
如果你的工作分支有大量的本地更改，但你仍然想变基，你可以做的一件事来帮助潜在的合并冲突是在变基之前首先 * 压缩 * 你的更改。
gstyhher2#
我建议使用git merge（不是因为它“更正确”，而是因为它可以完整地跟踪所有提交）。当你在寻找特定的行为（What's the difference between 'git merge' and 'git rebase'?）时，使用git rebase，但如果有疑问，git merge肯定不会扰乱你的repo。当然，要注意正确管理任何git无法自动解决的冲突。