git分支管理规范
# 分支管理
## 分支分类及作用
一共5类分支，分别为master，dev，feature， release，hotfix。
master分支：稳定版分支，线上运行的版本。
dev分支：开发分支，开发的主力分支。
feature分支：开发的子分支，用以开发产品的某个功能。
release分支：用以测试、修复线下bug及发布的分支。【不允许任何分支向release合并】
hotfix分支：用以修复线上bug的分支, 由于线上的代码只能有release分支发布，所以目前hotfix分支与release分支合为一支，存在且只存在release分支。
## 分支的管理策略
## 版本的命名策略
版本采用三段式，主版本号.功能版本号.修订版本号，例如：3.2.1。主版本号为3。功能版本号：2。修订版本号：1
上级版本号变动，所有下级版本号清0。例如版本号1.1.11。主版本改为2。则现版本号改为2.0.0
###产品改变完全不兼容前一个版本（主版本号加1）
主版本号加1，例如：原版本号为1.1.0 则现版本号为2.0.0。
###大功能变动（功能版本号加1）
每次遇到feature大的版本功能开发完毕，在测试完毕，release分支合并入master/dev分支前，在release分支上记一个功能版本tag标签，例如：2.1.0。依次递增1
###小功能变动与bug修复。（修订版本号加1）
每次遇到feature小的功能新增或者优化，在测试完毕，release分支合并入master/dev分支前，在release分支上记录一个小的三位版本tag标签，例如：2.1.1。依次递增1
每次遇到hotfix修改bug完毕，在release分支合并入master分支前，则记一个修复bug版本tag标签，例如：2.1.2。依次递增1
###
在操作分支时记得看下tag版本号，重要！重要！重要！
## 项目中的分支操作策略
### 在第一次开发时的分支操作（第一个开发feature功能的人）
不能在dev上分支上直接开发，要在拉取的feature中开发。在dev上开发的任何功能都会被管理策略回滚掉。
克隆远端仓库。
拉取/切换到dev分支 保证与origin dev分支一致。
从本地dev分支拉取feature分支（命名方式：featrue_产品名_功能_（产品下一个功能版本号）_拉取日期）。
将本地feature分支push到远端origin。
通知其他队友采用此分支。
### 在开发阶段中的分支操作（后续开发feature功能的人）
不能在dev上分支上直接开发，要在拉取的feature中开发。在dev上开发的任何功能都会被管理策略回滚掉。
克隆远端仓库。
拉取/切换到feature分支，保证与origin feature分支一致。
在feature分支开发相应功能，完成后push到origin。
### 在开发完成时的分支操作
此时不允许其他分支合并到dev分支
确保所有成员都已提交完毕，保证本地feature与origin feature分支一致，本地试运行。
本地切换分支到dev，拉取最新的dev分支。
将origin的feature分支合并到本地的dev分支。
push dev到远端origin上。
执行命令 git remote update ， 拉取origin各个分支。
执行命里 git remote prune origin，清除本地没有和远端服务器对应的分支。
如果存在origin release ，没有其他产品线在使用origin release分支的情况下，合并origin release 到 dev，然后再删除origin release。
如果有人在使用orgin release请协商进行，最好上线有节奏，不要一起上线。（注意操作，发现线上存在hotfix分支，则此release是为hotfix使用，不能删除，一切让位于hotfix，暂时不发布release测试）。
从origin dev[新建，新建，新建。重要的事情多说几遍，是新建release]本地分支release（若不存在origin release，才可以删除本地release）。
将本地release push到 origin release。
在Jenkins上发布到测试环境，通知测试队友开始测试。
此时不允许其他分支合并到dev分支
### 在测试阶段遇到bug时的分支操作
此时不允许其他分支合并到dev分支
本地拉取/切换到release分支，保持与origin release一致。
在release分支上修改线上遇到的bug。自测后push到origin
本地切换到dev, 更新dev，合并origin release到本地dev分支。
push 本地dev到origin dev。
### 在测试完毕后的分支操作
本地拉取/切换到release分支，保持与origin release一致。
在release分支上修改线上遇到的bug。自测后push到origin。
本地切换到dev, 更新dev，合并origin release到本地dev分支。
push 本地dev到origin dev。
本地拉取/切换到master分支，保持与origin master一致。
合并origin release到本地master分支上。
在本地master分支上打上tag（命名方式：产品名_本次版本号（feature上的版本号））。
push本地master到origin master上 包括tag标签【注意：一定要记得选择将自己打好的tag勾选push到远端】。
删除origin release。删除feature分支（本地和origin）。
### 在遇到线上bug时的分支操作
#### 如果origin已存在release分支
本地拉取/切换到dev分支，保持与origin dev一致。
合并origin release到本地dev分支上, push本地dev到origin dev。
删除origin release。
下面的步骤参考【#### 如果origin不存在release分支】
#### 如果origin不存在release分支
本地拉取/切换到master分支，保持与origin master一致。
从orgin master拉取本地hotfix分支（命名方式：hotfix_master版本号_修复bug_日期）
本地hotfix推送origin hotfix。
在本地hotfix上修复bug。
从hotfix上[新建，新建，新建。重要的事情多说几遍，是新建release]本地分支release
将本地release push到 origin release。
在Jenkins上发布到测试环境，通知测试队友开始测试。
重复4，5，6，7步骤直到线上bug修复完毕。
本地切换到dev, 更新dev，合并origin release到本地dev分支。
push 本地dev到origin dev。
本地拉取/切换到master分支，保持与origin master一致。
合并origin release到本地master分支上。
在本地master分支上打上tag（命名方式：产品名_本次版本号（小版本号））。
push本地master到origin master上 包括tag标签【注意：一定要记得选择将自己打好的tag勾选push到远端】。
删除origin release。
