Git Flow是中大型团队最稳妥的分支模型，因其通过develop、release/、hotfix/分支卡住关键节点，解决单用main+feature导致的预发布bug修复难、线上热修风险高、环境与分支映射混乱三大问题。
Git 分支模型不是选“最酷”的，而是选“最不拖慢交付节奏、最不容易搞混环境”的。对中大型团队来说，Git Flow 仍是当前最稳妥的起点——它把“谁在什么时候改什么”变成可预期的动作，而不是靠人盯人。
为什么不能只用 main + feature？
单靠 main 和一堆 feature/* 分支，会快速暴露三个现实问题：预发布阶段发现 bug 后没法只修 bug 而不带入未测试功能；线上紧急修复时，develop 里可能正跑着半成品代码，不敢直接合回去；测试、预发、生产三套环境对应不到稳定分支，每次部署都得靠人工 cherry-pick 或临时打 patch。
这些问题的根源是缺少中间状态分支。Git Flow 强制引入 develop、release/*、hotfix/* 就是为了卡住这几个关键节点：
-
develop是所有功能的“收口”，但不等于可发布——它只保证编译通过+单元测试过 -
release/*是发布前的“冻结线”，从此刻起禁止新增功能，只允许修复测试暴露的问题 -
hotfix/*必须从main拉出，修完立刻合回main和develop，否则develop会永久缺失这个修复
feature 分支命名和生命周期怎么管？
命名不是为了好看，而是为了快速过滤和自动化识别。比如 CI 流水线想跳过非功能分支的构建，就依赖分支名是否匹配 feature/.* 正则。
实操建议：
- 强制使用
feature/[JIRA-123]-login-refactor格式，其中 ID 是需求追踪号，避免出现feature/test或feature/xxx这类无法追溯的命名 - 合并进
develop后必须立即删除，否则三个月后仓库里会堆积上百个已失效的feature分支，git branch -a | grep feature变成心理阴影 - 禁止在
feature分支上直接提交到main或release——这类操作绕过 Code Review，是权限配置漏洞，不是流程问题
release 分支该不该保留？
不该。它的存在本身就是临时状态：从 develop 切出 → 测试反馈 bug → 开发者在该 release/* 上修 → 打 tag → 合并回 main 和 develop → 删除。
常见错误现象：
- 测试还没结束，开发又往
develop提了新功能，导致release/*合并回develop时冲突爆炸 - 发布失败后，团队把
release/*当成“备份分支”留着，结果下个版本误从它拉新release，漏掉中间的修复 - CI 配置没区分分支类型，
release/*触发了和feature/*一样的构建流程（比如跑全量集成测试），白白浪费资源
真正该持久化的是 tag：v2.4.0 对应 main 上那个 commit，而不是某个 release/2.4.0 分支的 HEAD。
hotfix 分支最容易被忽略的细节
很多人记得要从 main 拉，却忘了必须双合：既要合回 main（让生产环境立刻可用），也要合回 develop（避免下次发布又带这个 bug）。漏掉后者，等于给下个版本埋雷。
另一个高频坑是版本号处理：
- 如果当前
main是v2.3.1，热修复后应该打v2.3.2tag，而不是v2.4.0——后者属于功能迭代，不是紧急修复 - 不要在
hotfix/*分支上改package.json或pom.xml的版本号再合，而应在合并回main后，用git tag -a v2.3.2 -m "hotfix critical login timeout"显式标记 - 如果项目用语义化版本（SemVer），
hotfix只能递增 patch 位（x.y.Z），绝不能碰 minor 或 major
复杂点在于，有些团队把 hotfix 合并进 develop 后，发现它和正在开发的功能有冲突——这不是模型问题，是 develop 分支太久没同步 main 的修复。定期将 main 的最新 tag merge 进 develop（哪怕只是空提交）能大幅降低这类风险。
