开箱 GitLab Flow 的 Release 分支
Chirpy 项目从 v3.0.0 版开始，转型成了一个 gem-based 项目：支持在 RubyGems.org 上对外发布 gem 包，方便用户端升级。项目原本使用的是 GitLab Flow 的持续发布方案：采用 master 和 production 双子星分支。这对 gem 版本跟踪开始力不从心，所以计划将其转换成 release 分支。
Release 分支
GitLab Flow 的 Release 分支核心思想是：
主分支开发成熟后，商定一个语义化版本号，格式为：
<major>.<minor>.<patch>。如果是新的 major 或 minor 版本，就从主分支派生一个新的release分支，命名格式为<major>.<minor>-stable。不过release分支名命没有清规戒律，如果习惯 Git Flow 风格，也可以使用release/前缀，例如，release/<major>.<minor>。这样可以在 Git GUI 中把所有的release分支归并到release/目录下，方便查找管理。只有在版本发布后，出现严重缺陷需要紧急修复时，遵循「上源优先」法则，在主分支进行修复，然后 cherry-pick 到
release分支，然后在release分支上新建 tag，并增加 patch 版本号。
但是 GitLab 文档没有对 bump version (修改项目配置文件的版本号) 这个步骤的使用位置以及时机点出指引。所以在实际应用时，还需要根据自身项目情况进行细化思考。
包含 Bump version 的发布流程
经过一番思考与实验，个人觉得可以按照以下方式使用 release 分支：
在发布新的
major/minor版本，从主分支最后一个 commit 上实施 bump version，然后再派生一个新的release分支，并在其上面创建 tag。在发布新的
patch版本时，从主分支分离一个新的patch分支，在它上面完成 hotfix，以及 bump version。完成后，把patch分支用--no-ff方式 merge 到主分支。接着，把主分支的 merge 记录 cherry-pick 到release分支，然后在release分支上创建 tag。
在实际场景中，分支模型会类似下图：
主分支和 release 分支拥有一个相同的 bump version 记录，同时也是 minor 版本的第一个 tag。release 分支从第一个 hot-fix 起，与主分支各自拥有不同的提交轨迹，往后增加 patch 版本号（即 patch 大于 0）的 tag，只会存在于 release 分支。
借力 Git flow
上面说了对 release 分支的适配，但是开发过程的 feature 分支也值得花点笔墨提及一下。
Git Flow 成名已久，也是 GitHub Flow 与 GitLab Flow 的老前辈。现在主流的 Git GUI 基本都集成了 Git Flow，因此可以在 Git GUI 上享受创建 feature 分支的便利：
从 master 派生一个影子分支 develop，在它的基础上可以用 GUI 快速生成开发分枝 feature/<feat-name>，然后合并回 develop，同时自动删除 feature 分支。这些操作都是 Git Flow 的逻辑，在 GitLab Flow 模型上也可以通过 Git GUI 来享用。develop 分支某种意义上算是项目作者的私人长期 feature 分支，对于使用 Codacy 之类代码质量审核的项目，还能把 develop 分支作为长期监视的分支来控制代码品质。
结论
此次转型的好处是：每个版本的生命周期一目了然，同时可以随心所欲地把控指定的 commit 在指定的版本上发布，例如：在必须发布 patch 版本的时候，能有效避免主分支上的新功能的 commit 被提前发布（production 分支做不到这点）。再者，源代码的 Tag、Demo 网站、Wiki 文档，以及 gem 可以做到「四位一体」。个人觉得，GitLab Flow 的 release 分支模型配合 Git Flow 的 develop 分支，对个人开发者的开源项目来说是比较合适的。
Comments powered by Disqus.