提交的冲突解决：合并(merge)与变基(rebase)中的提交冲突处理

提交的冲突解决：合并(merge)与变基(rebase)中的提交冲突处理

昨天在调试一个嵌入式驱动时，遇到了一个典型场景：我本地的GPIO初始化代码刚改完，准备提交，结果发现队友已经把同一份文件的配置逻辑重构了。git pull一下，终端里赫然跳出CONFLICT (content)的提示。这种时候，你是选择merge还是rebase？两种方式都会遇到冲突，但处理起来的逻辑和影响完全不同。今天我们就来拆解这个问题。

冲突是怎么来的？

冲突的本质很简单：同一段代码在两次提交中被不同的方式修改了。Git 没法自动判断该保留哪一个，只能把决定权交给你。比如你改了某行配置寄存器地址的值，队友删了这行或者改成另一个值，冲突就出现了。

在合并（merge）和变基（rebase）中，冲突出现的阶段不一样。merge 是在合并两个分支的最终节点时一次性暴露所有冲突；rebase 则是把你的一系列提交逐个“重新播放”，每播放到一个与上游冲突的提交，就会暂停让你解决。所以 rebase 的冲突可能会多次出现，但每次冲突的影响范围通常更小。

Merge 冲突处理：保留历史痕迹

Merge 是最常见的整合分支的方式。执行git merge feature时如果遇到冲突，Git 会停下来，把冲突文件标记成下面这样：

<<<<<