Git 冲突与 AI 协助指南

本文档面向不熟悉 Git 冲突的开发者，说明如何让 AI 编码工具完整处理冲突，以及处理过程中必须遵守的业务边界。

总流程：Git 分支开发指南
测试环境冲突：Develop 测试环境合并说明
正式环境冲突：Main 正式环境合并说明

先理解冲突

Git 冲突不一定表示某一边写错了。它只表示两个分支修改了同一处内容，Git 无法自动判断最终结果。

冲突文件中通常会看到：

text 复制代码

正在合入分支的代码

Current、Incoming 和 HEAD 的含义取决于当前所在分支，不能只看按钮名称判断保留哪一边。

正确目标不是让冲突标记消失，而是得到同时符合两边有效需求的最终代码。

AI 可以完整处理什么

建议使用能够直接读取当前仓库、执行 Git 命令和运行测试的 AI 编码工具。可以交给 AI 完成：

读取 git status 和未解决文件列表。
查看冲突文件、附近代码、相关提交和现有测试。
分析两边修改分别要保留的功能。
修改文件并清除冲突标记。
补充或调整本次冲突直接涉及的测试。
执行 Diff 检查、代码规范、定向测试和必要构建。
汇总处理结果、验证结果和仍需人工确认的事项。

除非明确要求，AI 不应替你推送远端、合并 MR 或发布。提交代码前也应由开发者查看最终 Diff。

给 AI 的强制要求

每次交给 AI 处理冲突时，都必须包含以下要求：

默认保留冲突两边的全部有效功能，合并后的实现必须同时满足两边原有业务目标。不得仅为消除冲突而简单接受一边、删除另一边或弱化任一侧功能。只有当两边修改的是同一个功能点，并且代表互斥、无法同时成立的业务方向时，才暂停处理并请人工确认；AI 不得自行选择业务方向。

"同一个功能点的互斥方向"例如：

一边要求按钮始终显示，另一边要求同一按钮始终隐藏。
一边要求接口失败后自动重试，另一边明确要求同一接口失败后禁止重试。
两边为同一个字段定义了不能同时满足的计算规则。
两边对同一权限角色给出了相反的访问规则。

以下情况通常不需要人工选择，AI 应组合两边功能并完成验证：

两边修改同一文件中的不同功能。
一边重构代码，另一边增加功能，而且可以在重构后的结构中保留该功能。
两边分别增加不同校验、状态或错误处理，且业务规则不互斥。
一边修复缺陷，另一边调整展示，两者可以同时成立。

交给 AI 前

先停在冲突现场，并确认当前分支：

bash 复制代码

git status
git branch --show-current
git diff --name-only --diff-filter=U

不要在交给 AI 前：

点击"全部接受当前"或"全部接受传入"。
删除冲突标记后提交。
执行强制推送。
将 develop 合入开发分支。
同时开始处理其他不相关改动。

使用公司允许的 AI 工具，不要把密钥、个人数据或不允许外发的源码粘贴到未经授权的服务。

Develop 冲突提示词

适用于当前位于 develop，正在执行"开发分支 → develop"且发生冲突的场景：

text 复制代码

我正在将 <开发分支> 合入 develop，当前发生 Git 冲突。请完整处理这次冲突。

处理要求：
1. 先读取 git status、未解决文件、相关提交、附近代码和直接相关测试，说明两边修改分别要实现什么。
2. 默认保留 develop 中已有的全部有效功能，同时保留 <开发分支> 中本次需求的全部有效功能。
3. 不得简单接受 Current 或 Incoming，不得仅为消除冲突而删除、绕过或弱化任一侧功能。
4. 如果两边修改的是同一个功能点，并且业务方向互斥、无法同时成立，立即暂停并列出需要人工确认的具体选择，不要自行决定。
5. 其余可兼容的冲突由你直接完成文件修改，并补充或调整本次冲突直接涉及的测试。
6. 完成后检查未解决文件和冲突标记，查看完整 Diff，执行仓库规范要求的定向质量门禁。
7. 不要将 develop 合入开发分支，不要推送远端，不要合并 MR，不要处理本次冲突之外的问题。
8. 最后汇总保留了两边哪些功能、修改了哪些文件、验证结果以及是否仍需人工确认。

Main 冲突提示词

适用于当前位于自己的开发分支，已经执行"最新 main → 开发分支"且发生冲突的场景：

text 复制代码

我正在把最新 origin/main 合入 <开发分支>，当前发生 Git 冲突。请完整处理这次冲突。

处理要求：
1. 先读取 git status、未解决文件、相关提交、附近代码和直接相关测试，说明 main 与当前开发分支的修改分别要实现什么。
2. 默认保留 main 中已经上线的全部有效功能，同时保留当前开发分支中本次需求的全部有效功能。
3. 不得简单接受 Current 或 Incoming，不得仅为消除冲突而删除、绕过或弱化任一侧功能。
4. 如果两边修改的是同一个功能点，并且业务方向互斥、无法同时成立，立即暂停并列出需要人工确认的具体选择，不要自行决定。
5. 其余可兼容的冲突由你直接完成文件修改，并补充或调整本次冲突直接涉及的测试。
6. 完成后检查未解决文件和冲突标记，查看完整 Diff，执行仓库规范要求的定向质量门禁。
7. 不要将 develop 合入当前开发分支，不要推送远端，不要合并 MR，不要处理本次冲突之外的问题。
8. 最后汇总保留了两边哪些功能、修改了哪些文件、验证结果以及是否仍需人工确认，并提醒我重新合入 develop 测试。

把提示词中的 <开发分支> 替换为真实分支名。

AI 需要暂停的判断标准

AI 只有在以下条件同时成立时才应暂停：

两边修改的是同一个业务功能点。
两边表达的目标或规则互相冲突。
通过组合、兼容、条件化处理仍无法让两边功能同时成立。
仓库现有业务文档、测试和代码不能确定哪个方向是当前有效规则。

暂停时，AI 应给出：

冲突文件和功能点。
两边各自的业务行为。
为什么两种行为无法同时保留。
每个可选方向的影响范围。
需要产品、需求负责人或代码负责人确认的问题。

人工只需要确认业务方向。确认后，可继续让 AI 完成剩余修改和验证。

AI 完成后的检查

先确认没有未解决文件：

bash 复制代码

git status
git diff --name-only --diff-filter=U

第二条命令应没有输出。然后暂存 AI 处理的文件并检查：

bash 复制代码

git add <已解决的文件路径>
git diff --cached --check
git diff --cached

需要重点确认：

两边原有功能都存在，没有因重构或删代码而丢失。
人工确认过的互斥业务方向已按结论实现。
没有不相关文件进入 Diff。
测试确实覆盖冲突直接影响的行为。
AI 报告的测试、代码规范和构建结果可以复现。

完成检查和定向测试后再提交。提交命令按冲突场景分别参考：

无法继续时退出

如果 AI 已确认两边对同一功能点的业务方向互斥，或者你决定暂时不处理，可以取消本次合并：

bash 复制代码

git merge --abort
git status

如果 git merge --abort 失败，不要执行 git reset --hard 或强制删除文件。保留当前现场，交给熟悉 Git 的同事或 AI 工具继续排查。

最终原则

text 复制代码

默认情况
两边功能都保留 → AI 完整处理 → 检查 Diff 和测试

唯一需要人工核实的情况
同一功能点 + 业务方向互斥 + 无法同时保留
                    ↓
              人工确认方向
                    ↓
             AI 继续完成处理