Git合并冲突实战：当dev分支与master分支修改同一个README文件时
刚接触Git时，最让人头疼的莫过于合并冲突。记得我第一次遇到冲突时，屏幕上那些奇怪的<<<<<<<和>>>>>>>符号让我完全不知所措。但后来发现，只要理解冲突的本质，解决起来其实并不复杂。今天我们就用一个最简单的例子——两个分支同时修改README文件，来彻底搞懂Git冲突的解决之道。
1. 冲突场景搭建：制造一个可控的"事故"
让我们从零开始，亲手制造一个冲突，这样理解起来会更直观。假设我们有一个简单的项目，只有README.md文件：
# 初始化Git仓库 mkdir git-conflict-demo && cd git-conflict-demo git init # 创建初始README文件 echo "# 项目说明" > README.md git add README.md git commit -m "初始提交" # 创建dev分支并修改README git checkout -b dev echo "dev分支的修改" >> README.md git commit -am "dev分支修改README" # 切回master分支做不同修改 git checkout master echo "master分支的修改" >> README.md git commit -am "master分支修改README"现在，我们有了：
- master分支的README最后一行是"master分支的修改"
- dev分支的README最后一行是"dev分支的修改"
这两个修改在同一文件的同一位置，这就是典型的合并冲突场景。
2. 冲突的产生与识别
当我们尝试将dev分支合并到master时：
git checkout master git merge dev这时Git会友好地（虽然看起来不太友好）告诉我们：
自动合并 README.md 冲突（内容）：合并冲突于 README.md 自动合并失败，修正冲突然后提交修正后的结果。打开README.md文件，会看到类似这样的内容：
# 项目说明 <<<<<<< HEAD master分支的修改 ======= dev分支的修改 >>>>>>> dev这些标记的含义是：
<<<<<<< HEAD到=======之间是当前分支（master）的内容=======到>>>>>>> dev之间是要合并的分支（dev）的内容
3. 手动解决冲突
解决冲突的本质就是告诉Git：这两个版本我到底要保留哪个，或者如何组合它们。对于我们的README文件，有几种处理方式：
3.1 保留master分支的修改
删除dev分支的修改和冲突标记，保留：
# 项目说明 master分支的修改3.2 保留dev分支的修改
删除master分支的修改和冲突标记，保留：
# 项目说明 dev分支的修改3.3 合并两个修改
也可以选择保留两者的内容：
# 项目说明 master分支的修改 dev分支的修改提示：在实际项目中，合并内容时需要确保语义正确，不仅仅是简单拼接
4. 完成合并流程
确定好最终内容后，需要告诉Git冲突已经解决：
# 将修改添加到暂存区 git add README.md # 完成合并提交 git commit这时Git会自动生成一个合并提交消息，你也可以修改它。完成后，使用git log --graph可以看到分支合并的历史。
5. 使用图形化工具辅助解决
虽然命令行是基础，但图形化工具能让冲突解决更直观。比如VS Code内置的Git工具：
- 打开有冲突的文件，VS Code会高亮显示冲突区域
- 顶部会出现操作按钮，可以选择：
- 接受当前更改（master分支）
- 接受传入更改（dev分支）
- 保留两者更改
- 比较更改
注意：图形化工具虽然方便，但理解底层原理仍然很重要
6. 冲突预防策略
与其事后解决冲突，不如尽量减少冲突发生：
- 频繁合并：定期将master分支合并到开发分支，而不是等到最后
- 小步提交：小而专注的提交比大而全的提交更容易管理
- 沟通协作：团队成员修改相同文件时及时沟通
- 分支策略：
- 功能分支生命周期尽量短
- 使用
git pull --rebase而不是简单的git pull
# 推荐的工作流程示例 git checkout dev git fetch origin git rebase origin/master # 在本地先解决可能的冲突 # 测试通过后再合并到master7. 高级场景：多人协作中的冲突处理
在实际团队协作中，可能会遇到更复杂的情况：
7.1 没有目标分支推送权限时
如果你没有master分支的推送权限，标准的流程是：
- 在本地解决dev分支与master分支的冲突
- 推送dev分支到远程
- 创建Pull Request/Merge Request
- 由有权限的同事审核后合并
# 在dev分支上操作 git checkout dev git fetch origin git merge origin/master # 将master最新代码合并到dev # 解决冲突后 git push origin dev7.2 使用rebase替代merge
有些团队偏好使用rebase来保持线性历史：
git checkout dev git rebase master # 解决可能出现的冲突 git add . git rebase --continue # 如果放弃rebase git rebase --abortrebase的黄金法则：不要对已经推送到远程的分支执行rebase
8. 真实项目中的冲突解决经验
在大型项目中，冲突可能涉及多个文件、复杂的代码逻辑。以下是一些实用技巧：
- 理解上下文：不要机械地解决冲突，要理解为什么会有这些修改
- 利用差异工具：
git difftool可以并排比较版本差异 - 保留测试：解决冲突后确保运行测试，验证代码仍然正常工作
- 分段提交：复杂的冲突可以分多个小提交解决，便于回退
- 注释标记：临时添加注释标记冲突区域，解决后再删除
# 查看特定文件的冲突历史 git log -p -- README.md # 使用diff工具比较 git difftool HEAD HEAD~1 -- README.md记住，Git冲突不是错误，而是版本控制系统在尽职尽责地保护你的代码。每次解决冲突，都是对项目历史的一次精心维护。
