4、版本控制策略：Git 工作流（GitFlow，Trunk‑Based 等）
版本控制策略，说白了就是团队怎么管代码变更的历史。很多人觉得不就是`git add`、`git commit`嘛，哪那么多讲究。但我在几个项目里都见过，因为没用对工作流，合并冲突搞得通宵加班，上线回滚找不到版本……嗯，今天我们就聊聊这块。
4.1 为什么版本控制策略这么重要？
对我来说，一个好的 Git 工作流，至少要做到三件事：
- 可追溯——每个 feature、fix、release 都能找到对应的 commit 和发布历史。
- 可隔离——不同开发任务互不干扰，bug 修复不用等新功能上线。
- 可回滚——生产环境出问题，能快速切到上一个稳定版本。
令牌化平台工程里，CI/CD 管道和 Git 的分支策略是绑在一起的。分支剪不好，自动构建和部署就会乱套。
4.2 主流 Git 工作流速览
我自己用过的、也在团队里推行过的，主要有下面三种：
| 工作流 | 特点 | 适合场景 |
|---|---|---|
| GitFlow | 有 master、develop、feature、release、hotfix 分支，层次分明 | 有固定发布周期的产品，比如移动 App、企业软件 |
| Trunk‑Based | 所有开发集中在主干，短特性分支合并频繁 | 持续交付、微服务、SaaS，追求快速迭代 |
| GitHub Flow | 只有 main 和 feature 分支，通过 PR 合并 | 小型团队、Web 应用、创业项目 |
4.3 GitFlow：经典但有点重
我最早接触的就是 GitFlow，当时在做一个金融系统，每两个月发一次版。用 GitFlow 确实顺手：develop 分支上做日常开发，feature/xxx 分支完成后合并回来，到发版时拉 release/x.x.x 做最后测试和修复。
但后来发现一个问题：
- 分支太多，容易搞混。我记得有一次新同事把
hotfix合并到了feature分支，结果造成了一堆冲突。 - 每次发版都要走 merge 回 master 和 develop 两步，CI/CD 管道变得很复杂。
曾经我在一个项目中，因为 GitFlow 的 release 分支忘记合回 develop，导致下一个版本缺了之前修复的 bug。嗯，教训就是——流程越复杂，人工记忆越靠不住，最好在 CI 里加自动化检查。
4.4 Trunk‑Based Development：快节奏团队的首选
后来转到云计算平台团队，我们改用了 Trunk‑Based。说白了，就是所有开发人员都往 main（或者 trunk）上提交，短特性分支最长不超过一两天。
它的好处很明显：
- 几乎没有合并地狱——因为大家每天都在合并。
- CI/CD 管道只有一条主线，配置简单。
- 出了问题马上就能发现，因为代码变动的窗口很小。
- 小批量、高频次的提交（每次提交不超过一个功能点的改动）。
- 必须有强制的代码审查（Code Review）和自动化测试保护主干。
- 如果分支超过 2 天没合并，就应该被标记为“风险分支”。
我做过一个实验：团队从 GitFlow 切换到 Trunk‑Based 后，平均上线的周期从 2 周缩短到了 1 天。当然了，刚切换的第一个月比较痛苦，大家要改掉“攒一大堆代码再提 PR”的习惯。
4.5 其他工作流：GitHub Flow 与 GitLab Flow
GitHub Flow 其实是 Trunk‑Based 的简化版。只有 main 分支，所有功能都在 feature 分支上开发，通过 Pull Request 合入。适合 2‑10 人的小团队。
GitLab Flow 在 GitHub Flow 的基础上加入了“环境分支”（比如 pre‑production、production），把部署环境也纳入版本控制。我在做 DevOps 平台时用过这个模式，它把 CI/CD 跟分支直接映射，很直观。
4.6 怎么选？一张对比表
| 维度 | GitFlow | Trunk‑Based | GitHub Flow |
|---|---|---|---|
| 分支复杂度 | 高 | 低 | 低 |
| 发布频率 | 低频（月/季度） | 高频（天/小时） | 中频（周） |
| CI/CD 配置 | 多管道，需要分支过滤 | 单管道，简单清晰 | 单管道，C |
| 冲突风险 | 高（合并时爆发） | 低（日常合并） | 中（特性分支积累时间长时高） |
| 回滚成本 | 中（hotfix 方式） | 低（revert 或切版本） | 低 |
| 适合团队规模 | 10‑50 人 | 5‑30 人 | 2‑10 人 |
4.7 令牌化平台工程中的推荐实践
我们的课程聚焦在“令牌化平台工程 CI/CD 集成”，所以我给一个具体的落地建议：
- 优先考虑 Trunk‑Based，因为令牌化平台通常需要快速响应安全策略变更、事件溯源修复，频繁发布是常态。
- 如果必须保留 GitFlow，请把分支命名规范写进仓库的
.gitmessage或 CI 的校验规则里，比如feature/JIRA‑1234‑short‑desc。 - 加入提交信息规范：Conventional Commits（
feat:、fix:、chore:）配合分支策略，可以让 CI 自动生成 CHANGELOG 和语义版本。 - 用环境标记取代长期分支：比如使用
prod标签来标记生产部署的 commit，而不是维护一个release分支。
4.8 一张图看懂分支策略的选择
4.9 小结
版本控制策略没有银弹。我曾经在同一个团队里两种方案都试过，最后发现关键不在于哪个更“流行”，而在于你的 CI/CD 管道能否跟上分支模型。记住：
- 如果你们每天上线多次，别犹豫，上 Trunk‑Based。
- 如果你们每月发一个固定 release，GitFlow 依然好用，但务必用脚本自动化合并检查。
- 不管选哪种，都要把分支命名、提交规范、合并策略写在仓库的 CONTRIBUTING.md 里。