Question

我查看了更多关于git rebase导致分支转移的帖子，但是希望得到最好用的输入：git rebase vs git merge在以下场景中

考虑我有Master分支和分支-A

分支-A不仅仅是一个本地分支，但它也是一个远程分支。

工作流：

git co branch-A
git pull
Make some changes to branch-A
git add
git commit
git push

现在主人身上发生了更多变化

git co master
git pull
git co branch-A
git rebase master

现在我有很多冲突，git要求我解决冲突，添加并应用git rebase --continue 我解决了冲突

git add
git rebase --continue

现在我得到的消息是你的分支和origin / branch-A分歧并且分别有3个和1个不同的提交。使用git pull将远程分支合并到您的分支中。现在我从branch-A发出git pull

git pull

现在我收到一堆自动合并的消息，最后大部分文件都有冲突，我最终解决了我在发出git rebase之前解决的所有冲突 - 再次继续。解决所有冲突后，我发出

git add
git ci -m "Fixing the conflicts"
git push

现在一切正常，所有冲突都得到了解决。但为此，我最终做了两次冲突解决，一次是在git rebase之前 - 继续和其他因为分支转移而做git pull之后。

所以我的问题是，因为分支-A是远程的，它首先发布rebase是否正确，或者我是否应该遵循，

git co master
git pull
git co branch-A
git merge master
<resolve conflicts>
git add
git commit
git push

很抱歉很长的帖子，但我觉得，把我所看到的东西放得更清楚。非常感谢您浏览我的帖子，非常感谢您的回复。

Answer 1

最大的问题是，分支-A是否被其他人使用。如果是这样，你永远不应该重新定义它，因为rebase会重写历史记录。

您还将rebase与merge混合，因为pull执行隐式合并。在这种情况下使用rebase的唯一原因是线性化历史。

但是你为什么要在变革后退出？您应该只是push --force并覆盖历史记录。如果你坚持......

然而，

pull（merge）和rebase是通过不同历史获得相同合并内容的两种替代方法。你应该使用其中一个，但不能两个都使用。