最近自己搞了一个基于 gitlab 的适用于版本发布(非持续集成)的脱胎于 git-flow 的协作规范,发布出来大家可以作为借鉴。
Branch 规范
一共拥有以下几个(种)branch:
- master:master 上的都是 production-ready 的 stable 的代码。
- develop:作为开发的主分支,所有的 mr 都应当(先)合并到 develop 分支,定期 merge 到 master 发版。
- release-*:LTS 版本需要有独立的 branch,以作为后续(万一)hotfix 使用,精确到 minor version,如 release-v1.2,为长期保留的分支。
- feature/*:所有新的 feature(如新功能、性能优化)都应当先 checkout 到一个新的 feature 分支开发,原则上必须且只能 merge 到 develop 分支。
- bugfix/*:bug 的修复分支,原则上必须且只能 merge 到 develop 分支。
- test/*:test 分支主要做以下三件事:1. 增加 unit test;2. 修改仓库级别配置文件(如 .gitlab-ci.yml);3. 用来承载一些一次性的测试(不合入 develop)。
- hotfix/*:用来发布 hotfix 的分支,详见下节。
- release/*:用来做发版工作(如更新版本号,bugfix)的分支,还有一个作用是 freeze feature,不允许合入 feature,可以合入 bugfix,详见下节。
branch name 应当采用 下划线命名法。会在 ci 中对于 branch name 做强制检查,如果不合规会直接 fail。留出 test/* 的 branch 也是为了能够支持一些测试性的工作能够通过 ci 检查。
协作流程
开发流程
首先,确认自己在 develop 分支上;
git checkout -b feature/your_feature
;开发完成后,push 到 origin;
提 mr(如果是 性能优化,请在 description 中附带上 benchcmp 的结果),target branch 为 develop,并勾选最下方两个选项:
等待 review 通过,通过后点击 merge,请再次确认 squash 和 delete branch 被勾选:
如果 merge request 有 description,可以点击 “Modify commit message” 并点击最下方的 include description,然后再点击 merge:
done。
bugfix 流程
develop 上 bugfix
- 首先,确认自己在 develop 分支上;
git checkout -b bugfix/your_bugfix
;- 开发完成后,push 到 origin;
- 提 mr,target branch 为 develop,并如开发流程一样勾选最下方两个选项;
- 等待 review 通过,通过后点击 merge,请再次确认 squash 和 delete branch 被勾选;
- 如果 merge request 有 description,可以点击 “Modify commit message” 并点击最下方的 include description,然后再点击 merge;
- done。
release/* 上 bugfix
这里不需要直接 merge 回 develop 是因为 release/* 最终会 merge 回 develop。
- 首先,确认自己在 release/vX.Y.Z 分支上;
git checkout -b bugfix/your_bugfix
;- 开发完成后,push 到 origin;
- 提 mr,target branch 为 release/vX.Y.Z,并如开发流程一样勾选最下方两个选项;
- 等待 review 通过,通过后点击 merge,请再次确认 squash 和 delete branch 被勾选;
- 如果 merge request 有 description,可以点击 “Modify commit message” 并点击最下方的 include description,然后再点击 merge;
- done。
hotfix 流程
需要 merge 到 develop
- 按照 普通 bugfix 流程 完成 bug 修复,记得要更新代码中的版本号(为了防止 merge 到 master 后忘记 merge 回 develop);
- 切换到 master 分支上;
git checkout -b hotfix/your_hotfix
;- cherry-pick bugfix 的 commit;
- 检查无误后,push 到 origin;
- 提 mr,target branch 为 master,并如开发流程一样勾选最下方两个选项;
- 等待 review 通过,通过后点击 merge,请再次确认 squash 和 delete branch 被勾选;
- 如果 merge request 有 description,可以点击 “Modify commit message” 并点击最下方的 include description,然后再点击 merge;
- 切换到 master 分支上,打一个新的 tag;
- done。
仅需要 merge 到 master
适用于需要修复的 bug 在 develop 分支上已不存在的情况。
版本号的更新不需要同步到develop,在下次merge的时候解决冲突即可。
- 首先,确认自己在 master 分支上;
git checkout -b hotfix/your_hotfix
;- 修复完成后,新增一个独立的commit,更新代码中版本号,push 到 origin;
- 提 mr,target branch 为 master,并如开发流程一样勾选最下方两个选项;
- 等待 review 通过,通过后点击 merge,请再次确认 squash 和 delete branch 被勾选;
- 如果 merge request 有 description,可以点击 “Modify commit message” 并点击最下方的 include description,然后再点击 merge;
- 切换到 master 分支上,打一个新的 tag;
- 将第三步中更新版本号的独立的commit cherry-pick到develop分支上;
- done。
需要 merge 到 LTS release branch
- 根据情况,完成需要 merge 到 develop或者仅需要 merge 到 master中的一个;
- 切换到 release-vX.Y 分支上(待修复的分支);
git checkout -b hotfix/your_hotfix
;- cherry-pick hotfix 的 commit;
- 更新代码中版本号,检查无误后,push 到 origin;
- 提 mr,target branch 为 release-vX.Y,并如开发流程一样勾选最下方两个选项;
- 等待 review 通过,通过后点击 merge,请再次确认 squash 和 delete branch 被勾选;
- 如果 merge request 有 description,可以点击 “Modify commit message” 并点击最下方的 include description,然后再点击 merge;
- 切换到 release-vX.Y 分支上,打一个 tag;
- done。
发版流程
发版流程比较特殊,和其它流程有较大区别,请注意细节。
这么做的原因是,如果先把 release branch merge 到 develop 分支上,再将 develop 分支 merge 进 master 的话,可能会带上预料之外的 commit(在整理 release 的时候有新的 mr 被 merge 到 develop)。
- 首先,确认自己在 develop 分支上;
git checkout -b release/vX.Y.Z
;- 做一些发版需要的工作(如更新版本号等);
- 完成后,push 到 origin;
- 提 mr,target branch 为 master,**不勾选 squash 和 remove source branch**;
- 等待 review 通过,通过后点击 merge,请再次确认 squash 和 delete branch 未被勾选;
- 如果 merge request 有 description,可以点击 “Modify commit message” 并点击最下方的 include description,然后再点击 merge;
- 切换到 master,打一个 vX.Y.Z 的 tag。
- 再提一个 mr,target branch 为 develop,**不勾选 squash,勾选 remove source branch**;
- 等待 review 通过,通过后点击 merge,再次确认不勾选 squash,但 delete branch 被勾选;
- 如果 merge request 有 description,可以点击 “Modify commit message” 并点击最下方的 include description,然后再点击 merge;
- done。
CI check script
1 | !/usr/bin/env bash |