feature分支必须基于develop创建，禁止从main或其他feature分支拉取；CI需校验来源分支合法性；测试须覆盖单元、集成、E2E三层且全部通过；PR须附测试报告链接；归档前完成代码审查、冲突解决（rebase而非merge）、标签打点；测试资产须与分支生命周期对齐并隔离存放。
feature 分支必须基于 develop 创建，不能从 main 或其他 feature 分支拉
直接从 main 拉 feature 分支，会导致新功能跳过开发集成验证，上线后大概率出现依赖缺失或接口不兼容；从另一个 feature 分支拉，则隐含强耦合，破坏功能隔离原则。
- 正确做法：
git checkout develop && git pull && git checkout -b feature/user-profile-edit - CI 流水线应校验来源分支：若
git merge-base --is-ancestor origin/develop HEAD返回非 0，即拒绝 PR - GitLab/GitHub 可通过 branch protection rule + custom webhook 拦截非法来源分支
测试验证必须覆盖单元、集成、E2E 三层，且全部通过后才允许合并
仅跑单元测试就合入 feature 分支，常见于前端项目，但极易漏掉 API 契约变更、UI 交互断裂、权限逻辑错位等问题。测试未闭环就归档，等于把风险移交到 develop。
MergeIQ: Automatically Score & Prioritise PR Complexity for GitLab and GitHub
下载
使用四维度框架评估任意 GitLab MR 或 GitHub PR 的复杂度：规模（20%），认知负荷（30%），审查工作量（30%），风险/影响（20%）...
- 单元测试：覆盖核心逻辑路径，覆盖率 ≥ 80%（
jest --coverage或pytest --cov） - 集成测试：验证模块间调用，尤其关注跨服务调用、数据库事务边界（如
feature引入新表字段，需检查 migration 脚本是否被正确加载） - E2E 测试：至少覆盖主流程（如登录 → 进入编辑页 → 提交 → 成功提示），使用真实环境变量或 mock 网关（避免硬编码 staging URL）
- PR 描述中必须附带测试报告链接（如 Cypress Dashboard、Allure Report），不可仅写“已测”
归档关闭前必须完成代码审查、冲突解决、标签打点三件事
很多团队在 PR 合并后立刻删分支，结果发现线上 bug 需要回溯，却找不到对应 commit 的上下文——因为分支没了，git blame 和 git log --oneline feature/user-profile-edit 全部失效。
- 代码审查：至少 1 名非作者 reviewer 显式 approve，禁止 self-approve
- 冲突解决：合并前执行
git rebase develop（非merge），确保历史线性，避免无意义的 merge commit 干扰git bisect - 标签打点：合并后立即在
develop上打轻量标签，格式为feature/user-profile-edit/v1.0.0（非 annotated tag，避免冗余元数据） - 分支删除动作应由 CI 自动触发（如 GitHub Action 在 PR close 后执行
git push origin --delete feature/user-profile-edit），而非人工手动删
测试资产与 feature 分支生命周期必须严格对齐
自动化测试脚本、Mock 数据定义、环境配置模板如果没随 feature 分支一起提交和验证，就等于测试“裸奔”。更麻烦的是，这些资产常被误提进 main 或 develop，污染长期分支。
- 所有新增测试文件必须放在
tests/feature/user-profile-edit/目录下，与功能代码同分支提交 - Docker Compose 或
.env.example中新增变量，需同步更新文档说明（如 README.md 片段），否则下游无法复现 - CI 中启用
git diff --name-only origin/develop HEAD | grep "^tests/"校验：有功能变更就必须有对应测试变更，反之亦然 - 禁止将大体积测试数据（如 >5MB 的 JSON fixture）直接提交 Git，改用 Git LFS 或生成脚本（
python generate_test_data.py --size=1000）
