双周迭代下Git分支策略是必须对齐的执行契约：feature分支须14天内完成并绑定Sprint编号；develop仅接受带CI状态的PR且每日自动集成；hotfix需同步合并main和develop并规范命名；PR描述须含Sprint、验证步骤等强制字段。
双周迭代节奏下，Git分支策略不是选配，而是必须对齐的执行层契约——不匹配就卡点、不清理就堵车、不隔离就互殴。
feature分支生命周期必须卡死在14天内
敏捷双周迭代（Sprint）的核心是“可交付”，对应到Git，就是每个 feature/xxx 分支必须在Sprint开始时创建、结束前合并。超过14天未合并的分支，大概率已偏离当前需求上下文，强行合入会引入隐性风险。
- 创建分支时明确绑定Sprint编号：比如
git checkout -b feature/user-login-s2606（s2606 = Sprint 2026年6月第2周） - 每日站会后执行
git pull --rebase origin develop，避免本地偏离集成基线 - Sprint评审前2小时，该分支必须已通过CI流水线且无阻塞级PR评论；否则自动标记为“延期”，进入下个Sprint重排
- 合并后立即执行
git branch -d feature/user-login-s2606，远程分支由CI自动清理（需配置GitHub Actions或GitLab CI）
develop分支不是“万能中转站”，而是每日构建验证入口
很多团队把 develop 当作功能堆叠区，结果每天构建失败、测试跳过、谁都不敢合——这直接破坏双周节奏的确定性。
-
develop必须受保护：仅允许来自feature/*的PR合并，且PR必须带CI状态（单元测试覆盖率≥75%、E2E通过、无严重lint警告） - 每日凌晨触发一次
git merge --ff-only自动集成（非交互式），失败则立刻钉钉/飞书告警，责任人15分钟内响应 - 禁止在
develop上直接提交或修复；哪怕只改一行，也必须走fix/xxx分支 + PR 流程 - 如果某天
develop构建失败超2小时，当天所有新PR暂停合并，优先修复构建链路
hotfix分支要绕过develop直通main，但必须双向同步
线上故障不能等双周迭代，但也不能让hotfix变成“孤岛代码”——它必须同时进main和develop，否则下个Sprint会重复踩坑。
- 从
main创建：git checkout -b hotfix/payment-fail-260616 main（日期即问题发生日） - 修复后先推送到远程，再发起两个PR：一个合入
main（触发紧急发布），一个合入develop（确保后续迭代包含修复） - 合并
main后立即打tag：git tag -a v2.3.1-hotfix-260616 -m "fix: payment timeout on iOS" - 注意：hotfix分支命名中禁止出现空格、下划线以外的符号，CI脚本靠正则识别，
hotfix/payment-fail-260616可解析，hotfix/payment fail会失败
PR描述模板不是形式主义，而是Sprint闭环证据
双周迭代的验收，不止看功能上线，还要看协作过程是否可追溯。PR描述是唯一跨角色（开发/测试/PO）的轻量级协作凭证。
- 强制字段（CI检查）：
Related Sprint:（如 s2606）、Tested On:（环境+设备）、Verification Steps:（3步以内可手动复现） - 拒绝模糊描述：“修复登录问题” → 改为“fix(login): 401错误返回空body，改为返回标准error code + message（见JIRA-789）”
- 截图/录屏必须上传至PR附件，而非外链；外链失效后无法回溯验证动作
- PO确认上线后，在PR评论区写
@verified-by @product-owner，CI自动归档该PR到Sprint报告
真正卡住双周节奏的，往往不是技术难点，而是分支没删、PR没关、hotfix没同步develop——这些动作没有“技术含量”，但缺一不可。没人盯着的时候，靠流程卡点；有人盯着的时候，靠习惯落地。
