GitFlow 的核心在于分支角色严格对齐：main仅接受release/或hotfix/合并，develop为唯一长期集成分支，feature/需带Jira ID，release/和hotfix/*必须带版本号；git flow init配置不可随意修改；release分支冻结功能、仅修bug并同步至develop；hotfix必须从main拉出并用finish命令确保双合并；所有操作须验证提交历史一致性。
GitFlow 分支命名和生命周期必须严格对齐
GitFlow 不是“随便起个分支名就能用”的流程，它的价值全在分支角色的明确性上。一旦 develop 被当成临时功能分支、或 release/1.2 被直接合入 main，整个流程就失效了。
-
main（或master）只接受来自release/*或hotfix/*的合并，永远保持可部署状态 -
develop是唯一长期存在的开发集成分支，所有功能分支都从它拉出、最终也必须合回它 -
feature/*分支名建议带 Jira ID，比如feature/PROJ-123-login-ui，避免歧义 -
release/和hotfix/分支必须带版本号，如release/2.1.0，否则无法自动化打 tag
git flow init 之后别乱改配置
运行 git flow init 时看似只是按回车，但它会往本地 .git/config 写死五组分支前缀配置。这些不是“建议”，而是所有 git-flow 命令（如 git flow feature start）的执行依据。
- 如果手动把
feature-改成feat/，但没同步更新git config里的gitflow.branches.feature，命令会创建错分支 - 团队共用同一套命名规则，但有人本地改了前缀，
git flow release finish就可能删错分支、漏打 tag - 推荐初始化后立刻检查：
git config --get gitflow.branches.develop和git config --get gitflow.branches.master
release 分支不是“测试分支”，它要冻结功能并修 bug
很多人建了 release/1.5.0 就开始测，结果发现缺个按钮，又去 develop 提交新 commit，再 cherry-pick 过来——这等于绕过 GitFlow 的变更控制。
- 进入
release/*后，develop应继续接收新需求，但该 release 的功能增补必须终止 - bug 修复只允许在
release/*上提交，验证通过后用git flow release finish同时合并到main和develop - 如果修复需要复用
develop的某次提交，用git cherry-pick <commit-hash>，别 merge 整个分支 - 不走 finish 流程而手动合并，会导致
git flow认为 release 未结束，下次git flow release start可能报错
hotfix 必须从 main 拉，且要反向同步到 develop
线上炸了，你从 develop 拉个分支修完再合到 main？那 main 是修好了，但 develop 还带着那个 bug，下个 release 会重复出问题。
- 正确做法：从当前
maintag（比如v1.4.2）拉hotfix/1.4.3，修完跑git flow hotfix finish 1.4.3 - 这个命令会自动：① 合并到
main并打v1.4.3tag；② 合并相同修改到develop；③ 删除 hotfix 分支 - 如果跳过
finish手动操作，很容易漏掉第二步，导致 bug 在开发分支里“复活” - 注意：hotfix 的版本号应高于当前
main上的最新 tag，不能写成hotfix/1.4.2（和已有 tag 冲突）
GitFlow 看似是分支命名规范，实际是把“谁改什么、何时改、改完怎么同步”全部编码进分支拓扑里。最容易被忽略的不是命令怎么敲，而是每次 merge 后有没有人真去检查 develop 和 main 的提交历史是否符合预期——尤其当 finish 失败重试时，残留的 merge commit 往往埋雷。
