先理解冲突再编辑
冲突是一个问题，不是错误。标记展示了三个版本：共同基线、当前分支和传入分支。先理解双方为什么修改，再决定最终结果。
git status
git diff --name-only --diff-filter=U
# 打开每个文件，删除 <<<<<<<、=======、>>>>>>> 标记
git add src/payments/refund.ts
npm test
git commit步骤
- 用
git status --short与git diff --name-only --diff-filter=U列出冲突文件。 - 编辑每个文件到最终意图状态，删除所有冲突标记。不要在没有检查语义依赖的情况下直接选择一侧。
- 用
grep -rn '<<<<<<<\|=======\|>>>>>>>' . --exclude-dir=.git确认没有残留标记。 - 暂存已解决文件并运行测试：
git add <files> && npm test。 - 完成合并或 rebase：
git commit或git rebase --continue。
验证
- 工作树中没有冲突标记。
- 测试在合并结果上通过。
git diff HEAD^展示双方意图的组合，而不是整文件替换。- 合并提交信息解释了不明显的解决决策。
常见问题
如果一个分支删除文件、另一个分支修改了同一文件，必须明确文件是否应存在：保留删除用 git rm，保留修改用 git add。如果测试通过但行为错误，检查语义 diff，而不只是语法；配置和生成文件中的冲突容易隐藏意图差异。
限制
自动合并工具无法推断业务意图，必须由人决定正确行为。对整个文件选择 ours 或 theirs 可能静默丢弃无关改动。预防方式是缩短分支生命周期、频繁从主分支合并，并避免在特性分支中格式化整个文件。