Git中执行rebase操作时是否会出现代码冲突？

你的理解不对。rebase不仅会产生冲突，很多时候冲突处理的麻烦程度比普通merge还要高。你之前用rebase没碰到冲突，纯粹是当时操作的两个分支修改内容刚好没撞上，属于特殊情况，不是rebase本身没有冲突机制。

你看到的rebase最终结果，确实是当前分支的所有提交看起来像“接在目标分支最新提交后面”，但这个结果不是直接把提交搬过去就完事的，它的实际执行步骤是：

• 先找到当前分支和你要rebase的目标分支的最近共同祖先提交
• 把当前分支从共同祖先之后的所有提交，按先后顺序把每个提交的改动提取成临时补丁
• 把当前分支的指针直接挪到目标分支的最新提交位置
• 按原来的提交顺序，挨个把刚才存的补丁往当前指针位置打，每打一个补丁就做一次内容合并

这里每打一个补丁的过程，本质就是一次小型的三方合并，只要这个补丁改的内容和目标分支上已经存在的内容撞了——比如改了同一个文件的同一行，Git没法自动判断该留哪个版本，就会直接报冲突。你得手动把冲突改对，执行git add标记冲突解决，再跑git rebase --continue，它才会继续打下一个补丁。
因为是挨个打补丁，同一个文件甚至可能在打好几个补丁的时候反复出冲突，不像普通merge是把所有改动放一起做一次三方合并，只会集中出一轮冲突，这也是很多人觉得rebase冲突更麻烦的原因。

你从main分支切了个feature分支做需求，期间同事往main合了代码，改了src/utils/request.js里的请求超时逻辑，而你在feature上写代码的时候，先后3个提交都碰过这个文件的同一段逻辑。等你开发完想把main的最新代码rebase到feature上的时候，第一个补丁打上去就会直接冲突，解决完才会走后面的流程。

要是rebase到一半发现冲突太多理不清，随时可以跑git rebase --abort，分支会直接回到你执行rebase之前的状态，不会把原来的提交搞坏。

内容的提问来源于stack exchange，提问作者David