多人开发出现 Git 冲突时如何处理？

核心回答

多人开发出现 Git 冲突时，先用 git status 确认正在进行 merge 还是 rebase，以及哪些文件未合并；再对照双方修改和业务意图，把冲突文件编辑成正确的最终结果。处理后检查差异、运行相关测试，用 git add 标记已解决，再继续当前操作。

冲突表示 Git 无法自动决定怎样合并，不代表哪一方写错了。解决的目标也不是机械地选“我的”或“对方的”，而是保留仍然需要的行为，并处理两边改动之间的不兼容。

具体处理步骤

1. 确认状态和范围。 git status 会说明当前操作和冲突类型，git diff --name-only --diff-filter=U 可以列出未解决的文件。若合并尚未开始，先处理好已有未提交改动，再获取目标分支最新状态，按团队约定选择 merge 或 rebase。
2. 理解双方为什么改。 查看 git diff、冲突文件周边代码和相关提交，必要时与修改者对齐接口或业务规则。普通文本冲突中的 <<<<<<<、=======、>>>>>>> 分隔双方内容；三方合并工具还可以显示共同祖先，帮助判断各自改了什么。
3. 编辑最终结果。 保留、组合或重写所需逻辑，并删除冲突标记。文件删除与修改冲突、重命名冲突、二进制文件冲突不一定都有这种文本标记，需要根据最终应保留的文件结构处理。
4. 检查并暂存。 用 git diff --check 检查遗留冲突标记和空白问题，运行受影响模块的测试或构建。对解决好的文件执行如 git add -- config.json，再看 git diff --cached -- config.json 和状态，确认暂存的正是预期结果。git add 表示接受这个文件版本，并不证明业务逻辑已经正确。
5. 继续当前操作。 merge 冲突解决后执行 git merge --continue，也可以用 git commit 完成合并提交；rebase 则执行 git rebase --continue，它会继续重放剩余提交，后续还可能再次停在冲突处，重复处理即可。

例如，两个人分别在同一份配置中开启审计功能和链路追踪。若最终两个功能都需要，就应将配置合并为同时包含 audit 和 trace，而不是选一边覆盖另一边；之后还要确认配置格式合法，以及两个功能能否一起工作。如果改的是同一个超时参数，则需要根据调用链要求确定一个合适值，不能靠把两行都留下来解决。

merge 与 rebase 哪些地方不同

merge 合并双方分支的结果，通常通过合并提交保留分叉历史；rebase 则把当前分支的提交逐个重放到新基线上，产生新的提交，因此可能需要逐个解决冲突。

在普通 merge 中，ours 通常是当前分支，theirs 是待合入分支；rebase 的合并后端中，ours 是“新基线加上已经重放的结果”，theirs 是“当前正在重放的原分支提交”。所以不能把界面里的 ours/theirs 永远理解成自己的代码和同事的代码，使用整文件接受按钮前要看清内容。

如果需要放弃本次操作，merge 对应 git merge --abort，rebase 对应 git rebase --abort。它们不是继续处理的步骤，也不能在混有复杂未提交改动时承诺恢复所有现场。git rebase --skip 会跳过当前提交，不能把它当作“忽略冲突并保留全部修改”。

常见追问

没有冲突标记，就说明合并正确吗？

不一定。两个人修改不同位置时 Git 可能自动合并，但一方修改了接口参数，另一方仍按旧接口调用，仍会产生语义冲突。所以还需要查看最终差异，运行相关测试，并对齐接口变更。

推送时远端又更新了怎么办？

重新获取远端状态，再按团队约定整合新增提交、解决冲突并验证。强制推送不会替你合并代码，不能用它代替冲突处理；共享分支的历史改写尤其需要与协作者采用一致的流程。

怎样减少冲突？

保持提交和分支范围清晰，及时整合目标分支，提前沟通接口、公共配置等交叉修改。批量格式化、文件移动与业务变更分开，会更容易识别真正需要人工判断的冲突。

参考资料