[转载] 一种 Git 分支模型

原文出处： https://tyhopp.com/notes/a-git-branching-model
作者： Ty Hopp
原文发布日期： 2023-07-04
许可协议： 原文未声明显式开源协议，本文为其中文翻译，所有权利归原文作者所有。

一种 Git 分支模型

这是我在几个团队里用过的一种 Git 分支模型。

它不是什么新东西，只是我在网上没找到对它的详细描述，就写出来分享一下。

从步骤数量看，它介于 GitHub flow 和 Gitflow 之间。

• 有一条长期存活的 main 分支，作为整个仓库的 source of truth（唯一事实源）
  • main 分支开了保护，禁止删除、禁止直接 push
• feature（功能）、fix（修复）、refactor（重构）、test（测试）这些短生命周期分支都从 main 拉出来，PR review 通过后合回 main
  • 命名示例：feat-table-widget、fix-table-event-handling、refactor-table-cell-views、test-table-actions
  • 这些分支合进 main 之后立刻删掉
• 在约定好的日期，拉一条新的长期 release（发布）分支
  • 发版只针对 major（主版本）和 minor（次版本）规划，patch（修订号）不算（定义见 semver）
  • 拉出 release 分支这一步叫 branch cut
  • 命名示例：release-0.1、release-0.2、release-1.0
  • release 分支同样开保护，禁止删除、禁止直接 push
• release 分支拉出来后，会进入一段约定好的 stabilization（稳定化）期
• 稳定期内如果某个 release 需要修重要缺陷，就走 backport
  • 只有发布负责人（release lead）认定的重要缺陷才 backport
  • 新功能、测试、重构，以及次要缺陷的修复，都顺延到下一个 release
  • 改动要进 release 分支，得先 review 并合进 main
  • 然后从 release 分支拉一条短生命周期的分支，cherry-pick 这个修复，再开一个 PR 合回 release 分支
  • 把这个 PR 合进 release 分支
• 约定的稳定化期一到，就用 release 分支给项目发版
• 发版部署后如果还要打紧急修复，走 hotfix，流程和上面的 backport 一样
  • 同样只有发布负责人认定的紧急修复才会 backport
  • 除了 backport 这套流程，修复合进 release 分支后，还得补一个 patch 升级提交（比如 0.1.0 → 0.1.1）
  • patch 升级完，重新部署一次