Git 分支整合与冲突处理

Git 冲突最容易让人焦虑的地方，不是命令本身，而是不知道应该保留哪一边的改动。

很多时候，冲突并不是“当前分支和主分支谁更重要”，而是两边都在解决不同问题。正确的处理方式是先让功能分支回到最新主分支的基础上，再理解两边改动的目的，最后用实际验证确认结果。

为什么不能一直在旧主分支上开发

团队或多人协作时，其他人会不断向主分支提交新功能、修复和配置更新。如果一个功能分支长期不跟进主分支，等到最后再合并，冲突通常会更多，排查范围也更大。

在准备提交或合并前，先把本地主分支更新到远端状态：

1
git switch main
2
git pull

然后回到自己的功能分支：

1
git switch <功能分支>

接下来将最新主分支合并进来：

1
git merge main

这样做的目的不是立刻把功能分支合回主分支，而是先确认它能否与当前项目状态正常共存。

冲突发生时，先理解两边要解决什么

Git 会在冲突文件中标出两个版本的内容：

1
[当前分支 HEAD 的改动]
2
-------- Git 的冲突分隔线 --------
3
[主分支 main 的改动]

不要机械地选择“保留当前分支”或“保留主分支”。先看两边分别做了什么：

• 一边是否在修复已有问题，另一边是否在新增功能？
• 两边是否修改了同一条业务规则？
• 某一边是否已经被后续代码或配置替代？
• 合并后应该保留一个方案，还是把两个目的重新组合？

冲突标记只是 Git 告诉你“这里需要人为决定”。真正的决定来自当前需求、项目的真实状态和已经确认的实现边界。

解决冲突后，不要立刻认为完成

清除冲突标记、执行 git add 并完成合并提交，只说明 Git 已经接受了这次合并。它不代表合并后的项目一定能运行。

至少需要做三件事：

1. 阅读变更，确认没有误删一侧的关键逻辑。
2. 运行与改动直接相关的测试、构建或手动验证。
3. 检查工作区，确认没有遗漏的冲突文件或意外改动。

1
git status
2
git diff --check

如果改动涉及界面、文件处理、部署配置或用户流程，仅靠 Git 状态干净也不够。仍然应该运行对应场景，确认合并没有破坏用户实际会走到的路径。

一套更稳妥的整合顺序

1
更新本地主分支
2
→ 切回功能分支
3
→ 合并最新主分支
4
→ 理解并解决冲突
5
→ 运行相关验证
6
→ 再提交、推送或发起合并

这个顺序的价值在于，把“代码整合”和“功能正确”分开对待。Git 帮我们识别文本层面的冲突，但是否保留哪种行为、是否还能满足当前需求，仍然需要通过阅读和验证确认。

结语

分支整合并不是一次不得不做的收尾工作，而是减少后期风险的日常习惯。

越早把功能分支放到最新主分支上验证，越容易看清冲突到底来自哪里。真正可靠的完成标准也不是“冲突没有了”，而是合并后的项目仍然符合需求，并通过了与本次改动相符的验证。