Git分支管理规范

关于Git的一些分支管理规范。。。

 

1、分支与角色说明

Git 分支类型

master 分支（主分支） 稳定版本

develop 分支（开发分支） 最新版本

release 分支（发布分支） 发布新版本

hotfix 分支（热修复分支） 修复线上Bug

feature 分支（特性分支） 实现新特性

Gitlab 角色与项目角色对应关系

Owner（拥有者） Git 管理员

Master（管理员） 开发主管

Developer（开发者） 开发人员

Reporter（报告者） 测试人员

Guest（观察者） 其余人员

 

2、分支简明使用流程

一、每开发一个新功能，建立一个 feature 分支，多人在此分支上开发；

二、提测时，将 master 分支和须要提测的分支汇总到一个 release 分支，发布测试环境；

三、发现bug时，在feature分支上debug后，再次回到2；

四、发布生产环境后，将 release 分支合并到 master 分支，删除release分支；

 

3、建立新项目（master分支）

开发主管提交代码初始版本到master 分支，并推送至Gitlab系统；

开发主管在Gitlab 系统中设置master 分支为Protectd 分支（保护分支）；

Protected 分支不容许Developer 角色推送代码，但Master 角色能够推送代码；

 

4、进行项目开发（develop分支）

开发主管在master 分支上建立develop 分支（开发分支），并推送至Gitlab系统；

master 分支与develop 分支同样，有且仅有一个；

对于非并行项目可使用develop分支开发方式，对于多人并行开发项目，使用feature分支开发方式，但develop和feature开发方式不该同时使用；

 

5、开发新特性（feature分支）

每一个新需求或新的研究建立一个feature 分支；

命名规范：

f-分支建立日期-新特性关键字，例如：f-20150508-满立减；

推荐使用feature 分支，但feature 分支的生命周期不能跨一次迭代；

 

6、发布测试环境（release分支）

开发负责人需完成如下任务：

1. 确认要发布的feature 分支上的功能是否开发完毕并提交；

2. 建立release 分支（发布分支），将全部要发布的分支逐个合并到release分支，有以下状况：

①.feature分支（可能有多个）

②.master分支（期间可能有其余release版本更新到了master）

3. 命名规则：r-分支建立日期-新特性和待发布版本号，例如：r-201505081712-买立减v1.0.0，版本可根据须要添加;

4. 删除本次发布的全部feature分支;

5. 发布到测试环境，通知测试;

 

7、修复待发布版本中的Bug（feature分支）

若是发现bug，开发人员在feature 分支上修复测试人员提交给本身的bug，修复完成后，由负责人再次建立 release 分支，发布测试环境。

 

8、发布正式环境

开发负责人需完成如下任务：

1. 根据修复后的release分支再次将master合并，打包发布生产环境;

2. 确认发布成功，并线上验收经过后，将release分支合并到master分支;

3. 在master分支上建立标签，命名规则：tag-日期-新特性和版本号，例如：tag-201505081712-买立减v1.0.0，版本可根据须要添加，做为发版里程碑标记;

4. 删除对应release 分支;

 

9、修复线上Bug（hotfix分支）

线上的不一样版本出现了bug怎么办？开发负责人需完成如下任务：

1. 从master 分支某个tag 上建立一个hotfix 分支（热修复分支），通常是最新的tag应该和当前生产环境对应；

命名规则：h-分支建立日期-bug名称和待发布版本号，例如：h-201705081614-购物车点击没反应v1.0.1;

2. 开发人员完成Bug 修复，提交hotfix分支到测试环境验收经过;

3. 再次发布正式环境流程;

4. 将hotfix 分支合并到master分支;

5. 在master分支上建立标签，命名规则：tag-日期-新特性和版本号，例如：tag-201505081712-买立减v1.0.0，版本可根据须要添加，做为发版里程碑标记;

6. 删除hotfix 分支;

 

10、Git 的特别注意事项

因为 git 分支是基于指针的概念，因此分支速度很是快，当多个分支时，实际指针指向的是同一个文件，当文件被修改时，使用的是暂存区保存修改，此时并未提交到相应分支。

因此切换分支的时候，暂存区只有一个，因此切换分支以前，必定要将全部修改commit到当前分支，不然会在其余分支看到修改的内容，引发误解。

 

以上规范仅供参考，具体实践请依据团队具体状况自行调整。。。