2、版本控制与分支策略：Git Flow、GitHub Flow、Trunk-Based Development、分支命名规范
聊到自动化发布，版本控制和分支策略是绕不开的基石。说白了，你连代码怎么组织、怎么合并都没想清楚，后面的自动化流水线就是空中楼阁。我见过太多团队，一上来就搭 CI/CD，结果分支乱成一锅粥，发布的时候手忙脚乱。嗯，今天咱们就把这块硬骨头啃下来。
2.1 为什么分支策略这么重要？
你想想看，一个团队十几号人，甚至上百号人，同时往一个仓库里写代码。如果没有规矩，那不就是菜市场吗？我个人的习惯是，在项目启动的第一天，就必须把分支策略定死。这玩意儿就像交通规则，红灯停绿灯行，大家都遵守才能跑得快。
分支策略直接决定了你的发布节奏、回滚速度，以及团队协作的效率。选错了，后面全是坑。
2.2 Git Flow：经典但有点重
Git Flow 是我最早接触的分支模型。它把分支分成了几类：master、develop、feature、release、hotfix。听起来很全，对吧？
- master：只存稳定版本，每次合并都打 Tag。
- develop：日常开发的主干，所有 feature 都往这合。
- feature：从 develop 拉出来，开发完再合回去。
- release：从 develop 拉出来，做发布前的测试和修 Bug。
- hotfix：从 master 拉出来，紧急修复线上问题。
我在项目中遇到过用 Git Flow 的团队，说实话，对于大型项目或者需要严格版本管理的场景，它确实好用。但问题也很明显——分支太多了。每次发布都要走 release 分支，合并来合并去，光解决冲突就能耗掉半天。
2.3 GitHub Flow：轻量级的选择
GitHub Flow 就简单多了。它只有一个长期分支——main（以前叫 master）。所有开发都在 feature 分支上做，然后通过 Pull Request 合入 main。合入之后立刻部署。
说白了，这就是「主干开发 + 特性分支」的简化版。我特别喜欢它的简洁性。你想想看，没有 develop，没有 release，就一个 main。每次 PR 合并后，自动触发 CI/CD，直接上线。
但这里有个坑：你必须保证 main 永远是可部署的。如果谁合了一个坏代码上去，整个团队都得停下来修。我曾经有一次，同事合了一个没跑过测试的 PR，结果线上挂了半小时。嗯，从那以后，我们强制要求 PR 必须通过所有自动化测试才能合并。
2.4 Trunk-Based Development：极简主义
Trunk-Based Development（主干开发）就更激进了。所有开发者都在主干（trunk）上工作，或者拉非常短命的特性分支（通常不超过一天）。
它的核心理念是：频繁合并，小步快跑。我见过一些硅谷的团队用这个模式，他们一天能合并几十次代码。每次合并的改动量很小，所以冲突几乎不存在。
但说实话，这个模式对团队要求很高。你需要有强大的自动化测试覆盖，还要有 feature toggle（特性开关）来管理未完成的功能。我曾经尝试在一个传统企业推广 Trunk-Based Development，结果失败了。为什么呢？因为他们的测试覆盖率不到 20%，每次合并都提心吊胆。
2.5 分支命名规范
不管用哪种分支策略，命名规范必须统一。我个人的习惯是：
| 分支类型 | 命名格式 | 示例 |
|---|---|---|
| 功能分支 | feature/<描述> |
feature/user-login |
| 修复分支 | fix/<描述> |
fix/payment-bug |
| 发布分支 | release/<版本号> |
release/v1.2.0 |
| 热修复分支 | hotfix/<描述> |
hotfix/critical-security |
这里有个小技巧：分支名里最好带上 Jira 或 GitHub Issue 的编号。比如 feature/JIRA-123-user-login。这样你一看分支名，就知道它对应哪个需求。我在项目中吃过亏，有一次线上出了 Bug，翻遍所有分支都找不到对应的修复分支，就是因为命名太随意了。
feature/修复登录Bug。这在某些系统里会出问题，比如 Git 命令行或者 CI 工具对中文支持不好。所以，永远用英文命名。
2.6 如何选择？
说了这么多，到底选哪个？我个人的经验是：
- 小团队（1-10人）：GitHub Flow 就够了。简单、高效。
- 中型团队（10-50人）：Git Flow 或者 GitHub Flow + 严格的 PR 流程。
- 大型团队（50人以上）：Trunk-Based Development + feature toggle，前提是自动化测试要到位。
你想想看，没有完美的策略，只有适合你的策略。我见过用 Git Flow 用得风生水起的团队，也见过被 Trunk-Based Development 搞崩溃的团队。关键是要根据团队的实际情况来定。