一、目的
为了规范代码库分支管理和版本管理,使代码分支及版本结构清晰,方便维护,并避免由于维护造成的错误的版本发布等问题。
二、规范
Git分支管理
通常每个应用的代码将包括 master、develop、release、hotfix、feature分支,release、hotfix、feature 分支的命名规则分别为:release-*,hotfix-*,feature-* 。
整体流程图
分支类型
持久分支
需要持久存在的分支。
master
主分支,稳定代码,随时可供在生产环境中部署。每次代码发布后必需合并到master分支,并且每次发布都要打上对应的版本号标签(TAG)。
develop
开发分支,为开发服务,保存最新的开发成果。
非持久分支
开发完成,并合并/上线后,需要清理的分支。
release
发布分支,供测试使用,保存将要发布的版本。release分支上代码允许做小的缺陷修正,发布完后合并到master,develop分支。
hotfix
Bug修复分支 ,由master派生,修改完后要合并回master,develop分支。
feature
功能分支,由develop派生,必需合并回develop分支。
操作规则
- 每次提交必须写明注释,如果是修复Bug,请加上Bug号
- 处理同一问题多次commit需要进行合并
- 创建功能分支,名称要以feature-开头,加上特性名
- 创建发布分支,名称要以release-开头,加上预发布版本号
- 同时只允许一个release分支存在
- 创建Bug修复分支,名称要以hotfix-开头,加上Bug号
- 所有线上发布,都要打上tag,名称以v开头,加上发布版本号
- 合并分支时必须使用--no-ff参数,以保留合并历史轨迹
- 需要多人协作的分支才push到远程,否则保留在本地即可
- 完成功能,并将当前分支合并后,应删除版本库中的该分支
操作流程
开发新功能
开发阶段:
1. 从develop分支创建功能分支:
gitcheckout -b feature-20170831-sms develop
2. 开发完成并自测没问题后,切换到develop分支,并将功能分支代码合并到develop并推至远程。
git checkout develop
git merge --no-ff feature-sms-20170831
git branch –D feature-sms-20170831
git push origin develop
提测阶段:
4. 从develop创建发布release分支
git checkout -b release-1.1.0 develop
5. 如有Bug则在发布分支上进行提交
git commit “***Bug修复”
6. 将发布分支推到远程
git push origin release-1.1.0
发布阶段:
7. 提测完成后,将release合并到develop、master分支。
git checkout develop
git pull origin develop
git merge --no-ff release-1.1.0
git push origin develop
git checkout master
git pull origin master
git merge --no-ff release-1.1.0
8. 将master打上tag并发布到线上,
git tag v1.1.0
git push origin master
9. 删除发布分支(本地+远程)
git branch -D release-1.1.0
git push origin--delete release-1.1.0
修复线上Bug
1. 从master分支创建Bug修复分支:
gitcheckout -b hotfix-1101 master
2. 修复完后在测试环境切换至Bug修复分支进行测试,无问题后将代码合并回develop,master,将master发布至线上并打上tag:
git checkout develop
git pull origin develop
git merge --no-ff hotfix-1101
git push origin develop
git checkout master
git pull origin master
git merge --no-ff hotfix-1101
git tag 1.1.1
git push origin master
git branch –D hotfix-1101
多功能并行开发
一般情况下同时只允许一个release发布版本存在,里面保存当前功能开发提测版本,当有紧急需求需要优先开完并提测的情况下,有两种方式提供选择:
- 跟产品/测试沟通,将紧急功能需求与当前正开发功能进行合并提交测试。
- 从master创建一个分支来进行开发,走hotfix开发发布流程。
三、版本号管理
所有发布版本都需要有版本号。
版本号格式
v<主版本号>.<副版本号>.<发布号>
如:v1.1.0
主版本号(Major version)
设置时间:产品预计发布时。
设置规则:
1)项目功能进行重大修改,主版本号加1;
2)项目功能的接口协议重大修改,主版本号加1。
副版本号(Minor version)
设置时间:产品预计发布及版本预计更新时。
设置规则:
1) 主版本号变更时,副版本号置0;
2) 数据结构变更(新增或修改注释含义的情况除外),副版本号加1;
3) 若副版本号累加至超过20时,采用主版本号进位制,主版本号加1,副版本号重新置0。
发布号(Release)
设置时间:产品预计发布及版本预计更新时。
设置规则:
1) 主版本号或副版本号变更时,Release号置0;
2) 若发布的版本无数据结构变更,则Release号加1。