当前git是大部分开发团队的首选版本管理工具,一个好的流程规范可以让大家有效地合作,像流水线一样有条不紊地进行团队协作。
业界包含三种flow:
下面我们先来分析,然后再基于gitlab flow来设计一个适合我们团队的git规范。
先说git flow,大概是这样的。
然后,我们老的git规范是参考git flow实现的。
综合考虑了开发、测试、新功能开发、临时需求、热修复,理想很丰满,现实很骨干,这一套运行起来实在是太复杂了。那么如何精简流程呢?
我们来看业界的做法,首先是github flow。
Github flow 是Git flow的简化版,专门配合”持续发布”。它是 Github.com 使用的工作流程。
整个流程:
github flow这种方式,要保证高质量,对于贡献者的素质要求很高,换句话说,如果代码贡献者素质不那么高,质量就无法得到保证。
github flow这一套对于库、框架、工具这样并非最终应用的产品来说,没问题,但是,如果如果一个产品是“最终应用”,github flow可能就不合适了。
Gitlab flow 是 Git flow 与 Github flow 的综合。它吸取了两者的优点,既有适应不同开发环境的弹性,又有单一主分支的简单和便利。它是 Gitlab.com 推荐的做法。
Gitlab flow 的最大原则叫做”上游优先”(upsteam first),即只存在一个主分支master,它是所有其他分支的”上游”。只有上游分支采纳的代码变化,才能应用到其他分支。
对于”持续发布”的项目,它建议在master分支以外,再建立不同的环境分支。比如,”开发环境”的分支是master,”预发环境”的分支是pre-production,”生产环境”的分支是production。
只有紧急情况,才允许跳过上游,直接合并到下游分支。
对于”版本发布”的项目,建议的做法是每一个稳定版本,都要从master分支拉出一个分支,比如2-3-stable、2-4-stable等等。
gitlab flow 如何处理hotfix? git flow之所以这么复杂,一大半原因就是把hotfix考虑得太周全了。hotfix的意思是,当代码部署到产品环境之后发现的问题,需要火速fix。gitlab flow 可以基于后续分支,修改后上线。
综合上面的介绍,我们决定采用gitlab flow,按照版本发布的模式实施,具体来说:
新建分支,比如feat-test
开发代码,增加新功能,提交:
@GetMapping(path = "/test", produces = "application/json")
@ResponseBody
public Map<String, Object> test() {
return singletonMap("test", "test");
}
git commit -m "feat: add test code"
git push origin feat-test
提交代码后,可以提交mr
到master
,申请合并代码
Note:
研发组长,打开mr,review代码,可以添加建议:
开发同学根据建议修复代码,或者线下修改后commit代码。
研发组长确认没有问题后,可以合并到master。
合并完成,可以删除feat分支。
新功能开发好,可以进行提测。
版本格式:主版本号.次版本号.修订号,版本号递增规则如下:
主版本号:当你做了不兼容的 API 修改, 次版本号:当你做了向下兼容的功能性新增, 修订号:当你做了向下兼容的问题修正。 先行版本号及版本编译元数据可以加到“主版本号.次版本号.修订号”的后面,作为延伸。
主版本号为0,代表还未发布正式版本。
master分支,自动部署到开发环境(dev)
功能开发完成,并自测通过后,代码合并到待发布版本,
分支规则:
release-version
版本规则
主版本号.次版本号
构建时,自动增加修订号:
主版本号.次版本号.修订号
从最新的master新拉一个分支release-$version
,比如release-0.1
git checkout -b release-0.1
release-version会自动构建,版本号为version.
设定release-$version
分支为保护分支,不允许直接推送,只能通过merge不允许直接提交代码,接受MR
。
需要修改bug时,从release-version新拉分支,修改完成后再合并到release-version分支.
release-$version
拉的分支,如何测试?
release-$version
太多怎么办?
感谢您的认真阅读。
如果你觉得有帮助,欢迎点赞支持!
不定期分享软件开发经验,欢迎关注作者, 一起交流软件开发: