git分支设计是支撑敏捷交付的基础设施，需匹配迭代节奏：feature分支生命周期应控制在3–5天，cd团队用main作为唯一可部署分支，hotfix须从tag创建并同步合并至main和develop，pr合并后自动清理分支且禁用无意义合并提交。
Git 分支设计本身不创造价值，它只是让敏捷交付中“小步快跑、频繁集成、快速反馈”这三件事能真正落地的基础设施。如果分支策略导致 PR 堆积、合并冲突反复出现、hotfix 无法及时上线，那再好的敏捷流程也会卡在代码这一环。
分支结构必须匹配迭代节奏，而不是反过来
很多团队把 Git Flow 当成标准模板照搬，结果 feature/* 分支平均存活 12 天，develop 分支长期处于不可测试状态——这已经违背了敏捷“每个迭代可交付”的前提。
- 两周一个 Sprint 的团队，
feature/*分支生命周期建议控制在 3–5 天内，超时自动触发 CI 警告 - 持续部署（CD）团队应直接采用
main分支作为唯一可部署分支，所有提交需通过自动化门禁（如单元测试覆盖率 ≥80%、E2E 用例全通） - 若存在灰度发布需求，不要用
release/*分支隔离流量，而是用配置开关 + 特性标志（Feature Flag），分支只承载代码，不承载发布逻辑
PR 合并不是终点，而是分支生命周期的临界点
常见错误是 merge 完就认为任务结束，但此时 feature/* 分支仍保留在本地或远程，下个迭代拉取时容易误操作；更严重的是，merge 提交未带清晰上下文，后续回溯困难。
Conventional Git
下载
Conventional Commits v1.0.0 分支、工作树命名及提交信息规范，适用于 GitHub 与 GitLab 项目，用于创建分支和命名工作树等场景。
- 强制要求 PR 标题格式：
[JIRA-123] add password strength validation，且描述中必须包含“为什么改”和“如何验证” - CI 流水线应在 merge 成功后自动执行：
git push origin --delete feature/jira-123（删除远程分支）+git branch -d feature/jira-123（清理本地） - 禁止使用
git merge --no-ff生成无意义的合并提交；如需保留拓扑，用git rebase -i main整理提交历史后再 fast-forward 合并
hotfix 分支不是“特权通道”，它必须可追溯、可复现
生产事故修复最怕“先上线再说”，结果 hotfix 提交没同步到 develop，下次发版又把 bug 带回去；或者 hotfix 没经过完整测试路径，引发次生问题。
- hotfix 必须从
main当前 tag（如v2.4.1）创建，命名格式：hotfix/v2.4.1-login-null-pointer - hotfix 分支的 CI 流程不能跳过任何环节：必须跑全量单元测试 + 关键路径 E2E + 安全扫描（如 SCA）
- 合并 hotfix 时，必须同时向
main和develop（或当前活跃开发分支）推送，且两个 merge 提交的 patch 内容必须完全一致（可用git diff验证）
真正难的不是设计分支模型，而是让所有人遵守同一套轻量规则。比如 main 分支永远可部署这条底线，一旦被临时绕过（如“先合进去再修”），整个分支体系的信任基础就崩了一半。
