版本控制基础：Git工作流与分支策略
Git 分支策略这东西，说白了就是团队怎么协作写代码的规矩。你可能觉得分支嘛，随便拉一个就行——我一开始也这么想，直到有一次线上事故，因为 merge 乱了，回滚花了整整一个下午。嗯，从那以后我才认真琢磨起分支策略对流水线的影响。
流水线自动化最终要落地到代码上，而代码的流转路径，完全由分支策略决定。你想想看，分支拉错了、合并顺序乱了，流水线可能直接崩掉。所以，咱们得先搞懂三种主流的工作流。
Feature Branch Workflow
这是最基础、最容易上手的方式。所有新功能都从 main 拉一个独立的特性分支，开发完成后合并回去。没有复杂的规则，适合小团队或实验性项目。
- 流水线触发：每次 push 到特性分支就跑一次 CI 检查。
- 合并时机：通常通过 Pull Request 触发，合并前自动跑测试。
- 风险：如果多人长期不合并回 main，分支之间可能产生冲突，流水线也容易积压。
我个人习惯在特性分支名称里带上 JIRA 编号，比如 feat/JIRA-123-login，这样流水线日志里直接能定位到需求，排查问题快很多。
GitFlow Workflow
GitFlow 是经典的分支模型，有 main、develop、feature、release、hotfix 五类分支。层级分明，适合有固定发布周期的产品。
- 特性分支从
develop拉出，合并回develop。 - 准备发布时，从
develop拉release分支，只修 bug，不新增功能。 - 紧急修复直接从
main拉hotfix，修复后同时合并到main和develop。
曾经我在一个中大型项目中用了 GitFlow，流水线配置变得很复杂——每个分支类型要分别配触发器、构建步骤、部署目标。比如 release 分支要自动部署到预发布环境，main 分支部署到生产。如果分支名字不符合规范，流水线甚至会跑错脚本。
注意：GitFlow 对流水线团队要求高。分支多了，流水线规则容易写死，维护成本直线上升。我建议团队人数少于 10 人时慎用。
Trunk Based Development
Trunk Based 强调“小步快跑”。所有开发者直接在主干（main 或 trunk）上提交，或者拉短生命周期的分支（不超过一两天）。这是持续交付的黄金搭档。
- 分支尽量小，每次提交都经过 CI。
- 没有长期分支，减少合并冲突。
- 流水线触发频率极高，自动化程度必须高。
我记得在一个 SaaS 产品团队里推行 Trunk Based，刚开始大家很抵触，觉得太危险。后来我们加上了特性开关（Feature Toggle），把未完成的功能藏起来，主干永远保持可部署状态。流水线变得极其简单——只有一条管道：提交 → 构建 → 测试 → 部署。出问题几秒钟就回滚。
三种工作流对比
| 特性 | Feature Branch | GitFlow | Trunk Based |
|---|---|---|---|
| 分支数量 | 少（主分支+特性分支） | 多（5类固定分支） | 极少（几乎只有一个主干） |
| 流水线复杂度 | 低 | 高 | 低 |
| 合并频率 | 低（功完成才合） | 中等（按周期合） | 高（每天多次合） |
| 冲突风险 | 中 | 高（release/hotfix 容易乱） | 低（每次合入量小） |
| 适用场景 | 小团队、原型开发 | 大型产品、固定版本发布 | 持续交付、微服务、DevOps 成熟团队 |
分支策略对流水线的实际影响
你可以这么理解：分支策略决定了流水线要处理多少种“入口”。
- 触发规则：GitFlow 需要为每个分支类型写单独的触发条件（比如
branch: release/*或branch: hotfix/*），而 Trunk Based 只盯住主干。 - 构建产物管理：特性分支的构建产物要不要留存？GitFlow 的 release 分支产物往往要存档，而 Trunk Based 只留主干的产物。
- 环境部署映射：比如 GitFlow 里，develop 分支自动部署到测试环境，release 分支部署到 staging，main 部署到生产。一旦分支名写错，部署就乱套。
核心原则：分支策略越简单，流水线越稳定。我个人倾向于 Trunk Based + 特性开关。如果团队真的需要 GitFlow，别忘了把分支命名规则硬编码到流水线验证脚本里，否则早晚出事。
避坑指南
- 我曾经遇到一个项目，开发用了 GitFlow，但 hotfix 分支合并回 main 后忘记同步到 develop，导致下个版本上线把紧急修复覆盖了。后来我在流水线里加了一个自动合并步骤：当 hotfix 合并到 main 时，自动创建 PR 到 develop。
- 我还见过有人把特性分支拉得太长（一个月），结果合并时冲突几百个文件，流水线跑了三个小时才失败。改成每天合并一次后，问题消失了。
- 嗯，这里要注意：不要盲目追求“标准 GitFlow”。大多数团队的发布节奏根本不需要 release 分支，直接用 tags 打版本更省事。
总结一下
分支策略不只是“怎么拉分支”的技术问题，它是流水线设计的上层建筑。选错了，后面全是坑。我个人推荐先小团队用 Feature Branch，等持续集成成熟了，果断切换到 Trunk Based。至于 GitFlow，除非你的产品有严格的版本周期而且团队纪律性很强，否则别碰。
记住：流水线是跟着分支策略走的，别反着来。你想想看，如果分支策略天天变，流水线脚本不也得天天改？那自动化还有什么意义？