Develop 测试环境合并说明

本文档说明如何将自己的开发分支合入 develop，供测试环境验证。

Develop 是什么

develop 是测试环境的集成分支，可能同时包含多个尚未上线的需求：

text 复制代码

需求 A ──┐
需求 B ──┼──→ develop → 测试环境
需求 C ──┘

因此：

开发分支可以合入 develop。
不要从 develop 创建开发分支。
不要把 develop 合入开发分支。
不要直接在 develop 上修改具体需求。
不要用 develop 向 main 发布。

下文命令中的 <开发分支> 是占位符，需要替换为真实分支名。

合并前检查

先回到自己的开发分支，确认修改已经提交并推送：

bash 复制代码

git switch <开发分支>
git status
git push

git status 应提示工作区没有未提交修改。若仍有文件未提交，先确认原因，不要带着不明修改继续合并。

方式一：通过 MR 合并

新手优先使用 MR，因为可以在合并前集中查看 Diff、CI 和冲突。

在代码平台创建：

text 复制代码

Source: <开发分支>
Target: develop

合并前依次检查：

Source 和 Target 是否正确。
Diff 是否只包含当前需求。
CI 和构建是否通过。
是否意外带入其他需求代码。
平台是否提示冲突。

检查通过后，开发人员可以自行 Merge，不要求其他人员审批。

如果 MR 提示冲突，不要执行"develop → 开发分支"。转到本文的冲突处理，在本地 develop 上合入开发分支并解决。

方式二：在本地直接合并

先确保自己的开发分支已经提交和推送，然后更新本地 develop：

bash 复制代码

git switch develop
git pull --ff-only origin develop
git log --oneline origin/develop..develop
git merge <开发分支>

合并前，git log 应没有输出；如果列出了提交，说明本地 develop 还有未推送内容，应先确认这些提交的归属。

没有冲突时，先检查本次合并结果：

bash 复制代码

git status
git diff ORIG_HEAD --stat

确认无误后推送：

bash 复制代码

git push origin develop

如果 git pull --ff-only 失败，说明本地 develop 和远端历史不一致。不要强制推送，也不要自行改写公共分支历史；先交给熟悉 Git 的同事或 AI 工具分析。

冲突处理

为什么要在 develop 上解决

假设 develop 已经包含需求 A、B、C，而你的开发分支只包含需求 A：

text 复制代码

develop:  A + B + C
你的分支: A

如果将 develop 合入你的分支，你的分支也可能包含 B、C。之后再用该分支向 main 发起 MR，就可能把尚未允许上线的代码一起带入正式环境。

所以本场景的固定规则是：

text 复制代码

开发分支 → develop 发生冲突
              ↓
       在 develop 上解决

直接合并时发生冲突

执行以下命令后：

bash 复制代码

git switch develop
git pull --ff-only origin develop
git merge <开发分支>

Git 可能显示：

text 复制代码

CONFLICT (content): Merge conflict in ...
Automatic merge failed; fix conflicts and then commit the result.

先查看现场，不要继续推送：

bash 复制代码

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

此时推荐让具备仓库访问权限的 AI 编码工具完整处理冲突。告诉 AI 当前正在"将开发分支合入 develop"，并要求它同时保留 develop 和开发分支中的全部有效功能。

只有两边修改的是同一个功能点，并且业务方向互斥、无法同时成立时，AI 才应暂停并请人工确认，不能自行选择一边。可直接使用 Develop 冲突提示词。

MR 提示冲突

如果"开发分支 → develop"的 MR 提示冲突，不要在开发分支执行：

bash 复制代码

git merge develop

正确做法是改为本地合并：

bash 复制代码

git switch develop
git pull --ff-only origin develop
git merge <开发分支>

然后在 develop 上处理冲突。处理完成并验证后，将 develop 推送到远端。

冲突解决完成

先确认已经理解并整理好每个冲突文件的最终逻辑，然后暂存解决结果：

bash 复制代码

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

git status 中不能再有 unmerged paths。完成定向测试后提交并推送：

bash 复制代码

git commit -m "merge: 解决 develop 合并冲突"
git push origin develop

推送后继续在测试环境验证当前需求。

同一功能点方向互斥

如果 AI 判断两边修改的是同一个功能点，并且业务方向互斥、无法同时成立，应保持冲突现场并请需求负责人或相关代码负责人确认。人工确认方向后，再让 AI 继续完成修改和验证。

如果需要先恢复到合并前状态：

bash 复制代码

git merge --abort
git status

取消合并只会回到合并前状态，不会删除已经正常提交的开发分支代码。

测试发现问题

不要直接在 develop 修复需求。回自己的开发分支修改：

bash 复制代码

git switch <开发分支>

# 修改并检查代码后
git add <文件路径>
git commit -m "fix: 修复测试发现的问题"
git push

然后重新执行"开发分支 → develop"并继续测试。

检查清单

当前操作方向是"开发分支 → develop"。
没有将 develop 合入开发分支。
合并结果同时保留了 develop 和开发分支中的有效功能。
同一功能点存在互斥方向时已经完成人工确认。
git status 中没有未解决冲突。
Diff、CI、构建和定向测试均正常。
测试修复仍然提交在自己的开发分支。

测试通过后，继续阅读 Main 正式环境合并说明