git flow适用于有明确发布节奏、需多版本维护及支持多分支验证的中大型项目；不适用于持续部署的web服务或小团队无专职测试的场景。

Git Flow 不是万能模板，用错场景反而拖慢交付。是否采用 Git Flow，取决于你团队是否有明确的版本发布节奏、是否需要长期维护多个生产版本、以及 CI/CD 是否支持多分支验证流程。

什么时候该用 Git Flow 的五类分支结构

Git Flow 的 main、develop、feature/*、release/*、hotfix/* 五类分支，本质是为「按版本号交付」服务的。如果你的项目每 2–4 周发一个带语义化版本（如 v2.1.0）的正式包，且上线前需经过 QA 团队多轮回归测试、性能压测、合规检查，那 Git Flow 能帮你把变更卡在 release/* 分支里反复打磨，而不污染 develop 上的新功能开发。

反过来说，如果你们走的是持续部署（CD），每天向预发环境推多次、主干 main 始终可上线，那就没必要引入 release/* 和双合并（release → main 再 → develop），直接用 GitHub Flow 更轻量。

• 适合 Git Flow 的典型场景：银行核心系统升级、车载固件 OTA 版本、SaaS 平台年度大版本
• 不适合的信号：release/1.2.0 分支建了 3 周还没合入，期间 develop 又提交了 27 次新功能 —— 这说明流程已卡住，不是分支策略的问题，而是需求拆分或排期失控
• 团队规模小于 5 人、无专职测试角色时，硬套 Git Flow 容易让 release/* 变成“没人管的孤儿分支”

feature 分支合并前必须做的三件事

很多冲突和线上问题，其实源于 feature/* 分支在合并前没做好同步与验证。不是 merge 命令一敲就完事。

Lovefromio Github

使用 `gh` CLI 与 GitHub 交互。通过`gh issue`、`gh pr`、`gh run` 和 `gh api` 管理 issue、PR、CI 运行以及高级查询。

下载

• 从 develop 拉最新代码并解决本地冲突：git checkout develop && git pull && git checkout feature/login && git merge develop（别用 rebase，它会重写历史，导致 PR 中的 commit hash 失效）
• 确保所有自动化检查通过：CI 流水线跑完单元测试 + 接口测试 + 静态扫描，状态是绿色，不是“跳过”或“忽略失败”
• 手动验证关键路径：比如你改了支付回调逻辑，就得真调一次沙箱支付，看订单状态是否正确流转，不能只信单元测试覆盖率数字

release 分支删除前容易漏掉的关键操作

release/* 分支不是合并完就能删的。删早了，会丢掉版本锚点；删晚了，又可能被误当开发分支继续提交。

• 必须先打 tag：git tag -a v1.2.0 -m "Release 1.2.0"，tag 要打在 main 上，且 message 里明确写清变更范围（例如“含 feature/user-auth、hotfix/payment-timeout”）
• 必须确认 develop 已同步该次 release 的全部修复：执行 git checkout develop && git merge --no-ff release/1.2.0，否则下个版本会漏掉热修
• 远程分支删除后，本地仍可能残留引用：运行 git fetch --prune 清理 origin 的 stale tracking refs，否则下次 git branch -a 还会看到已删的 remotes/origin/release/1.2.0

hotfix 分支为什么不能直接从 develop 创建

hotfix/* 必须从 main（或对应 tag）拉，这是 Git Flow 的铁律。因为它的目标是「立刻修复线上正在运行的版本」，而 develop 里可能混着未测试的新功能，合进去等于把不稳定代码直接推上生产。

常见错误操作：git checkout -b hotfix/db-conn develop → 修复完合到 main → 线上数据库连接是好了，但顺带把 develop 里那个没测过的权限模块也上了，结果权限全乱了。

• 正确流程：先 git checkout main && git pull 拿到当前线上真实代码，再 git checkout -b hotfix/db-conn
• 修复后，必须双线合并：先 git checkout main && git merge --no-ff hotfix/db-conn，再 git checkout develop && git merge --no-ff hotfix/db-conn
• 如果线上跑的是 v1.1.3，但 main 分支已提前合了 v1.2.0 的部分代码，那就得从 v1.1.3 tag 创建 hotfix：git checkout -b hotfix/db-conn v1.1.3

Git Flow 的复杂性不在命令本身，而在每个分支背后隐含的协作契约：谁负责合、何时合、合完谁验证、不按契约走就会断链。最容易被忽略的，是 release/* 合并后对 develop 的反向同步 —— 这一步漏掉，下个版本就永远缺了这次修复，直到某天有人翻 tag 记录才意识到。