Git 工作流选型：Gitflow、GitHub Flow 与主干开发

Git 只提供提交、分支、合并和标签等机制，不会强制团队使用某一种工作流。工作流是团队约定，应该服务发布节奏、风险控制、代码评审和部署能力，而不是为了“分支看起来完整”而增加流程。

1. 三种常见模式

模式	常见结构	更适合	主要成本
轻量功能分支 / GitHub Flow	稳定默认分支 + 短期功能分支 + PR	持续集成、频繁发布、团队想用少量规则交付	需要自动化检查、review 和发布保护可靠
主干开发	多数变更小批量、频繁集成到主干，未完成功能用 feature flag 隔离	多人高频协作、CI 快、愿意拆小改动的团队	对测试、回滚、兼容和开关治理要求高
Gitflow	长期 `main` 与 `develop`，配合 feature、release、hotfix 分支	有明确版本窗口、维护多个已发布版本或较严格发布冻结	分支较多、集成延迟和冲突成本上升，CI/CD 流程更复杂

这些是模式，不是互斥的宗教。团队也可能采用短期功能分支，同时只在发布窗口使用 release 分支。Atlassian 当前将 Gitflow 标注为 legacy workflow 并指出它在持续交付场景下会带来额外成本；它仍可能适合计划式发布。先问“我们为什么需要这条长期分支”，再决定是否引入。

2. 轻量功能分支的基本循环

下面以 origin 举例；默认分支名称、合并策略和保护规则都由仓库配置决定，不要假设一定叫 main 或 master：

git status --short --branch
git fetch origin
git switch -c feat/small-change origin/<default-branch>
git add path/to/reviewed-file
git diff --cached
git commit -m "feat: describe the change"
git push --set-upstream origin feat/small-change

创建分支前确认工作区状态。若默认分支名称未知，先从仓库页面或 git remote show origin 核实；不要把尖括号占位符原样执行。开 PR 后通过自动化和代码评审，再按仓库策略合并。短分支应及时同步并删除已合并的远端分支，但本地清理前确认分支已合并且不再需要。

3. Gitflow 分支职责

main：已发布或可发布的版本历史。团队也可能用其他默认分支名；Gitflow 原型常写 master，不应照抄到新仓库规则中。
develop：下一发布周期的集成分支。所有 feature 基于这里开始并回到这里。
feature/*：短期功能开发分支，完成后通过 review 合并至 develop。
release/*：冻结一组待发布功能后，集中修复发布阻断、版本号和文档问题；完成后将修复合回集成线并创建版本标签。
hotfix/*：从当前生产版本对应提交创建紧急修复，发布后把修复同步到后续开发分支。

Gitflow 的关键不是分支前缀，而是同一修复必须进入所有仍被维护的版本线。多条长期分支会出现合并漏项；release/hotfix 结束时要明确回合并目标并验证 CI。

4. 一个简化的 Gitflow 操作示例

假设仓库明确采用 develop 集成线，并且你已确认没有同名本地分支：

git fetch origin
git switch -c feature/search-filter origin/develop
git push --set-upstream origin feature/search-filter

功能完成后通过 PR 合并到 develop。发布冻结后，维护者基于集成分支创建 release/2.4.0，只接受发布阻断修复；具体合并目标、标签和部署由团队发布手册定义。不要把多个分支命令当成可以跳过 review、测试或数据库兼容检查的快捷发布流程。

紧急修复同样先确认当前线上版本：

git status --short --branch
git log --oneline --decorate -12
git switch -c hotfix/login-timeout <production-tag-or-commit>

占位符必须替换成仓库中核实过的标签或提交。修复通过评审后合入生产分支，并按团队约定同步至仍受支持的 release/develop 分支；完成后验证没有漏掉测试和配置变更。

5. 如何选型

先画出真实交付路径：提交之后由谁 review、哪些检查必过、如何部署、如何回滚；
若默认分支始终保持可发布，部署频繁且 CI 快，优先评估短期功能分支或主干开发；
只有当多个并行版本、固定发布窗口或较长冻结期确实存在时，才增加 develop/release 长期分支；
用 feature flag、向后兼容迁移和小批量提交降低未完成工作合入主干的风险；
每隔一段时间检查等待合并时长、冲突量、回滚频率和发布前冻结成本，删掉不再提供价值的分支规则。

不要在没有团队协议时擅自重命名默认分支、重写共享历史或删除远端分支。工作流变更需同步分支保护、CI、部署脚本、发布文档和每个活跃协作者。

6. 操作前安全检查

查看 git status --short --branch，确认当前仓库、分支和未提交改动；
合并前检查 git log --graph --oneline --decorate --all 与 git diff <base>...HEAD；
处理冲突后逐文件审阅，再运行项目检查，避免直接接受整边覆盖；
合并或删除分支前确认目标分支、部署环境和保护规则；
已共享提交优先用新提交修正，不对他人依赖的分支执行强制推送。

官方资料

GitHub Flow：短期分支、PR 与 review 的轻量协作模式。
Atlassian：比较 Git 工作流：集中式、功能分支、Gitflow 与 Forking 模式及其权衡。
Atlassian：Gitflow：Gitflow 的分支职责和发布流程，并明确其 legacy 定位。
git switch 与 git merge：分支切换与合并的命令行为。