Posts 开箱 GitLab flow 版本发布分支模型
Post
Cancel

开箱 GitLab flow 版本发布分支模型

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

GitLab flow 的 Release 分支

版本发布的分支模型1核心思想是:

master 开发成熟之后,商定一个版本号,如果是新的最小版本,就从 master 分支派生一个新的发布 (release) 分支,命名为 <major>-<minor>-stable

gitlab_flow_release_branches GitLab flow release branches

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

对 Release branches 的适配

在遵循 GitLab flow「上源优先」策略的前提下,可以考虑在 master 上进行 bump version,完成后立即 git-merge 到 release 分支,然后在 release 上进行 git-tag。Gem 打包发布在最新的 tag 上进行。线上 Demo 站点也是根据最新的 tag 来生成。

对于 Hotfix,在 master 上进行开发,完成并通过测试后 merge 到 最新release 分支。旧版本的 release 就可以放弃维护了,因为超过最小版本号的 bug 不能叫 Hotfix 了,陈年老 bug 呆在 master 上过日子就好了。

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

借力 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 作为长期监视的分支来控制代码质量。

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

总结

此次转型的好处是:每个 relase 的生命周期一目了然,同时,源代码的 tag、在线网站 / 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.