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的黄金法则不要对已经推送到远程的分支执行rebase8. 真实项目中的冲突解决经验在大型项目中冲突可能涉及多个文件、复杂的代码逻辑。以下是一些实用技巧理解上下文不要机械地解决冲突要理解为什么会有这些修改利用差异工具git difftool可以并排比较版本差异保留测试解决冲突后确保运行测试验证代码仍然正常工作分段提交复杂的冲突可以分多个小提交解决便于回退注释标记临时添加注释标记冲突区域解决后再删除# 查看特定文件的冲突历史 git log -p -- README.md # 使用diff工具比较 git difftool HEAD HEAD~1 -- README.md记住Git冲突不是错误而是版本控制系统在尽职尽责地保护你的代码。每次解决冲突都是对项目历史的一次精心维护。