Git 代码分支管理

 

1. 目的：
   1. 为了让每个人实现需求产生的代码不和其他人还未发布或者正在实现需求所产生的代码不产生冲突
   2. 灵活的上线某个需求，可以测试和上线任何小的或者独立的业务需求
   3. 避免多个需求在同一个分支当中，突然要上线其中某一个需求，因为代码耦合而无法独立上线某个需求相关的代码的情况
   4. 提高线上（生产环境）代码安全性
2. 固定分支和功能
   1. master/prod（生产环境） 固定且受保护分支，此分支所有代码和生产环境保持一致，贯穿整个项目周期。所有人不可也没有权限push代码到此分支
3. 其它分支
   1. 新的需求和bug修改分支
4. 新建分支场景
   1. 新的需求
   2. bug修复
5. 新建分支规范
   1. 一般情况下，新的需求和bug修复都是基于生产环境下开发和修复，所以不论是新的需求还是bug修复都基于生产环境分支“master/prod”创建新的分支，命名规范见第6节
   2. 如果某个需求包含了多个功能点，如果存在某个功能点先上的情况，需要对需求进行拆分，方便单个功能上线且不用等该需求所有功能点开发完成之后再上线
6. 分支命名规范
   1. 如果是需求，xq开头，如果有需求编号可以跟上需求编号，中间以下划线“_”隔开,例如xq_10001
   2. 如果是bug修复，bug开头，后面跟上bug编号，还是以下划线“_”隔开,例如：bug_21005
   3. 如果没有需求编号或者bug编号，开头不变，下划线后面可以用几个简单的单词概况分支的目的
   4. 如果一个需求存在功能点单独发布的情况，可以在需求编号后面加上功能点简要描述，通过几个单词描述，以下划线“_”隔开
   5. 如果要测试或者发布多个（大于1）需求，release开头，后面跟上创建分支的日期，中间用下划线“_”隔开，例如：release_20191108，并且在创建的分支描述信息中填写该分支包含了哪些分支，以及简要的内容描述
7. 功能测试
   1. 如果是单个的需求或者bug修复，直接在对于需求或者bug的分支进行部署
   2. 如果是同时上线多个需求，可以参考第6.4，建立新的合并分支并部署，这么做的好处是，可以灵活的选择是上多个分支的需求或者上某一个，并且其他分支代码不受影响
8. 分支合并
   1. 在需求或者bug对应的分支测试通过并上线之后，由master/prod分支的管理员来合并已经上线的分支代码到master/prod分支
   2. 发起分支合并请求可以由分支对于的开发者或者生产分支的管理者来发起
9. 分支删除
   1. 在需求或者bug对应的分支合并到生产分支master/prod之后，分支开发者需要删除对应的分支，避免Git上分支太多不利于管理
10. 
    1. 新来了一个需求，禅道上没有建立需求，没有需求编号，但是有内部编号是v1.3.5，按照此文档的规范，操作步骤如下

1. 新建分支，因为这是一个新的需求，并且不能和其它需求和分支耦合

2.基于master/prod建立新的分支

3.分支名称参照6.1，命名为xq_1.3.5

4.注意：如果这个版本内容不多，不存在先上某个功能点的情况下，则只需要一个分支，如果内容很多，可能会先上某个功能点，则此版本的需求需要按照功能点来建立分支

5.在新的分支上进行业务的开发，提交代码和push都只能在当前分支上进行，不能将此分支的代码push到任何其它分支上，避免业务的扩散和影响其他人的代码

6.在当前分支的业务开发到测试阶段，需要pull最新的生产代码（master/prod）到当前分支，避免遗漏在本分支开发期间新上线的业务

7.将本分支代码发布到开发环境和前端联调，如果不需要，直接进入下一步

8.将本分支代码发布到测试环境供测试人员测试，注意，如果同一个项目需要测试多个分支，可以单独发布某个分支，如果分支功能和其它分支功能有交互，可以新建一个合并分支（参考6.4），pull需要测试的分支代码到新建的合并分支并发布到测试环境

9.测试通过，将代码发布到生产环境

10.合并已经发布到生产环境的代码分支到生产分支（master/prod）

11.删除已经发布的分支

12.结束

       10.2  如果是线上产生了bug，需要对bug进行修复，除了分支的命名和第一个例子不同，其它步骤一样