Git分支管理规范

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

一、分支与角色说明

Git 分支类型

master 分支(主分支) 稳定版本

develop 分支(开发分支) 最新版本

release 分支(发布分支) 发布新版本

hotfix 分支(热修复分支) 修复线上Bug

feature 分支(特性分支) 实现新特性

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

Owner(拥有者) Git 管理员

扫描二维码关注公众号,回复: 2143549 查看本文章

Master(管理员) 开发主管

Developer(开发者) 开发人员

Reporter(报告者) 测试人员

Guest(观察者) 其他人员

 

二、分支简明使用流程

1、每开发一个新功能,创建一个 feature 分支,多人在此分支上开发;

2、提测时,将 master 分支和需要提测的分支汇总到一个 release 分支,发布测试环境;

3、发现bug时,在feature分支上debug后,再次回到2;

4、发布生产环境后,将 release 分支合并到 master 分支,删除release分支;

 

三、创建新项目(master分支)

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

开发主管在Gitlab 系统中设置master 分支为Protectd 分支(保护分支);

Protected 分支不允许Developer 角色推送代码,但Master 角色可以推送代码;

四、进行项目开发(develop分支)

开发主管在master 分支上创建develop 分支(开发分支),并推送至Gitlab系统;

master 分支与develop 分支一样,有且仅有一个;

对于非并行项目可以使用develop分支开发方式,对于多人并行开发项目,使用feature分支开发方式,但develop和feature开发方式不应同时使用;

五、开发新特性(feature分支)

每个新需求或新的研究创建一个feature 分支;

命名规范:

f-分支创建日期-新特性关键字,例如:f-20150508-满立减;

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

六、发布测试环境(release分支)

开发负责人需完成以下任务:

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

2. 创建release 分支(发布分支),将所有要发布的分支逐个合并到release分支,有如下情况:

①.feature分支(可能有多个)

②.master分支(期间可能有其他release版本更新到了master)

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

4. 删除本次发布的所有feature分支;

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

七、修复待发布版本中的Bug(feature分支)

如果发现bug,开发人员在feature 分支上修复测试人员提交给自己的bug,修复完成后,由负责人再次创建 release 分支,发布测试环境。

 

八、发布正式环境

开发负责人需完成以下任务:

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

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

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

4. 删除对应release 分支;

九、修复线上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 分支;

 

十、Git 的特别注意事项

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

所以切换分支的时候,暂存区只有一个,所以切换分支之前,一定要将所有修改commit到当前分支,否则会在其他分支看到修改的内容,引起误解。

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

猜你喜欢

转载自www.cnblogs.com/imyalost/p/9301732.html
今日推荐