一、目的

为了规范代码库分支管理和版本管理，使代码分支及版本结构清晰，方便维护，并避免由于维护造成的错误的版本发布等问题。

二、规范

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发布版本存在，里面保存当前功能开发提测版本，当有紧急需求需要优先开完并提测的情况下，有两种方式提供选择： 

1.  跟产品/测试沟通，将紧急功能需求与当前正开发功能进行合并提交测试。
2.  从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。