Posts 开箱 GitLab Flow Release 分支
Post
Cancel

开箱 GitLab Flow Release 分支

Chirpy 项目从 v3.0.0 版开始,转型成了一个 Gembased 主题:支持在 RubyGems 上对外发布 gem 包,方便用户端升级。项目已有的分支模型使用 GitLab flow 的持续发布型方案,采用 masterproduction 双子星分支,而今对 Gem 版本跟踪开始力不从心,所以我计划将其转换成面向版本发的分支模型。

GitLab flow release 分支

release-branches

GitLab flow 发布分支1核心思想是:

  • master 分支开发成熟后,商定一个语义化版本号,如果是新的 minor 版本,就从 master 分支派生一个新的 release 分支,命名格式为 <major>-<minor>-stable

    Release 分支名命没有清规戒律,如果习惯 Git Flow 风格,也可以使用 release/ 前缀,如,release/<major>.<minor>,这样可以在 Git GUI 中把所有的 release 分支归并到 release 目录下。

  • 只有在版本发布后,出现严重缺陷需要紧急修复时,遵循「上源优先」法则,在主分支进行修复,然后 cherry-pick 至发布分支,新建 tag,并增加修复版本号。

但是 GitLab 文档没有对在何时、哪个分支进行 bump version(修改项目配置文件的版本号)进行说明。所以在实际应用时,还需要根据自身项目情况进行细化思考。

Bump version

bump-version

作为前述问题的回应,bump version 可以考虑在 release 分支上进行,接着立即 git-tag。完成后,把最新的一个 commit 从 release 分支 cherry-pick 到 master 分支。这里使用 cherry-pick 而非 merge 有两个好处:

  • 保持 release 分支独立
  • 避免合并时产生冲突,因为 master 的提交进度绝大多数时间都走在 release 之前

Gem 打包发布在最新的 tag 上进行。线上 Demo 站点也是根据最新的 tag 来生成。

对于 hotfix,遵循 GitLab flow「上源优先」策略,在 master 上进行开发,完成并通过测试后 cherry-pick 到 最新release 分支。旧版本的 release 就可以放弃维护了,因为超过 minor 版本号的 bug 不能叫 hotfix 了,陈年老 bug 呆在 master 上过日子比较好。

线上 Demo 站点的 CD 从之前的 production 触发改为 tag 触发,这样就可以做到 Demo 和最新的 Gem 包一致。

借力 Git flow

上面说了对 release 分支的适配,但是开发过程的 feature 分支也值得花点笔墨提及一下。

Git flow2 成名已久,也是 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 作为长期监视的分支来控制代码质量。

develop 分支需要注意的是,每次合并到 master 之前,只允许拥有一个 feature 的提交历史。因为这样就不用担心会和开源贡献者的 PR 在 master 分枝上出现抢位现象。

总结

此次转型的好处是:每个版本的生命周期一目了然,同时可以随心所欲地把控指定的 commit 在指定的版本上发布,例如:在必须发布 patch 版本的时候,能有效避免 master 分支上的新功能的 commit 被提前发布(Environment 分支做不到这点)。再者,源代码的 Tag、Demo 网站、Wiki 文档,以及 Gem 可以做到「四位一体」。个人觉得,GitLab flow 的版本发布模型配合 Git flow 的 develop 分支,对个人开发者的开源项目来说是比较合适的。

引用

This post is licensed under CC BY 4.0 by the author.

Docker 运行 Shadowsocks

-

Comments powered by Disqus.