【转载于码云代码管理最佳实践】我们团队怎么做分支管理

我们团队怎么做分支管理

• 合并代码将别人代码合丢了
• 发布了并不计划上线的代码
• 代码分支非常多
• 长期在一个分支上开发
• 多人共用一个分支开发
• 每次提交代码都有冲突
• 不知道别人分支做什么用的

分支管理一直是技术团队最基础的但是却最容易忽视的一块，如果你团队中也遇到上述的问题，那么，建议你可以看看我们是怎么解决这些问题的。

我们团队近80人，大大小小上百个项目，历史原因一些项目属于单体应用，开发者众多，期间存在架构调整，还有其他团队负责的模块，最近的一些项目都是微服务，相对来说规模小一些，开发人员也不会太多。
但是，这么多项目，每隔一段时间总会出一些因为代码管理不善造成的严重线上故障，究其原因，都是低级错误，技术管理者都不好意思去向老板汇报，因为这是管理的问题，为此，我们制定了代码分支管理规范，在此，也分享给大家。

分支命名

工作中遇到很多人分支命名相当随意，比如直接叫dev、develop的，或者用姓名全拼或者首字母的：zjl、zhoujielun，其实这跟写代码的时候变量命名为a、b是差不多的，没什么意义，3个月回过头来看都不知道这个分支是什么的。

规范

分支有两类，常驻分支和短期分支，我们规定，一个工程必须有以下三个常驻分支：

常驻分支

• master 主分支， 应该永远处于稳定状态，合并进 master 分支的代码必须是经过测试的代码，该分支随时可能被合并进 RELEASE 分支。其他任何分支均从master分支创建。

• RELEASE 发布分支，该分支只能接受合并master分支代码，其它分支一律禁止直接提交或者合并到该分支，该分支随时可能被发布到生产环境。

• testing 测试分支，该分支供测试使用，任何新功能、bug修复等操作后的分支都应该先合并到testing分支进行测试，并且testing分支禁止被合并到开发分支、master和RELEASE分支。

短期分支

新特性分支

新特性开发分支
需要开发新功能时，需要从 master 分支拉出一个 feature 分支，命名规范：dev-[feature ]-[version],如果一个feature有多人参与开发，可以在后面加上个人标记作为本地分支，可以不用push到远程（如果开发时间比较长需要），但需要合并到本地特性分支后并推送到远程项目feature开发版本分支。

【例子】
dev-taxinfo-v181218 个税信息v181218版本的开发分支，根据年月日生成版本号
dev-taxinfo-v181218-lupeng 个税信息v181218版本的开发分支，卢鹏的本地分支，务必是姓名全拼（不用push到远程）。如果多人开发一个功能，每个人都自己建这么一个分支，一个完整的功能开发完成之后再合并到dev-taxinfo-v181218.

bug修复分支

紧急修复 bug 分支，命名约定为 fix-[bugname]-[username]，以fix开头，连接bug的特性。

分支保护

master和RELEASE默认被设置为protected，（码云如何设置保护分支？）仅项目的master权限成员才能进行merge操作，其它权限成员需要线上发起merge request进行合并。这样避免项目成员随意合并代码，合并的代码都会经过固定的人review。

代码提交规范

执行git commit的时候，我们对提交说明（commit message）暂时没有严格的要求，暂定如下简单的要求：

禁止使用‘update’、‘fix bug’等无意义的提交说明，如果是修复bug，请说明修复什么bug；如果是其它提交，请描述本次提交的主要涉及的新功能、样式修改或者文档补充等。

合并代码流程

发布测试环境：

当我们某个新功能开发完成之后，需要发布测试环境，具体合并代码流程如下：

• 更新本地各个分支代码，与远程一致保持最新（主要涉及master、dev-taxinfo-v181218、testing）。
• 将master分支代码合并到dev-taxinfo-v181218，如果有冲突，在dev-taxinfo-v181218分支解决冲突并且push到远程。
• 将dev-taxinfo-v181218分支代码合并到testing分支

注意事项：

• 解决冲突必须自己的分支dev-taxinfo-v181218解决，保证与其它的分支只是merge关系，不直接commit。
• 严禁将testing代码合并到自己的开发分支dev-taxinfo-v181218，否则别人还没有准备上线的代码可能在不知情的情况下被提前发布。
• 任何情况下，都尽量保证自己本地的各个分支代码与远程保持一致，是最新的。

发布线上：

当我们开发完成并且经过测试通过之后，需要将代码发布上线，具体合并代码流程如下：

• 更新本地各个分支代码，与远程一致保持最新（主要涉及master、dev-taxinfo-v181218、RELEASE）。
• 将master分支合并至dev-taxinfo-v181218，如果有冲突，在dev-taxinfo-v181218分支解决。
• 将dev-taxinfo-v181218合并到master分支，推送到远程。（理论上经过第2步，这步不会出现冲突）
• 将master分支合并至RELEASE,推送到远程。（master分支和RELEASE分支代码理论上是一致的，这一步也不会出现冲突）
• 待项目发布之后，dev-taxinfo-v181218分支删除，如有新的需求或者版本迭代，从master分支拉取新分支比如：dev-taxinfo-v190118。

当然，由于对master和RELEASE分支设置了protected，非master成员无法直接merge代码，这个时候需要：

• 更新本地master和dev-taxinfo-v181218分支至最新。
• 将master分支合并至dev-taxinfo-v181218，如果有冲突先解决冲突，并且push到远程。
• 在gitee上面发起merge request，从dev-taxinfo-v181218到master。
• 由项目的master成员去审核处理，并且从master合并到RELEASE，并且负责发布上线。

成员管理

在码云平台，仓库成员权限可以以下几种：

成员角色	权限
访客（登录用户）	对于公有仓库：创建 Issue、评论、Clone 和 Pull 仓库、打包下载代码、 Fork 仓库、Fork 仓库提交 Pull Request、下载附件
报告者	继承访客的权限。
观察者	继承报告者权限私有仓库：创建 Wiki、可以 Clone 下载代码、可以 Pull、不能 Fork
开发者	创建 Issue、评论、Clone 和 Pull 仓库、Fork 仓库、打包下载代码、创建 Pull Request、 创建分支、推送分支、删除分支、创建标签（里程碑）、创建 Wiki、可上传附件，可删除自己上传的附件，不能删除他人上传的附件、
管理员	创建 Issue、评论、Clone 和 Pull 仓库、打包下载代码、创建 Pull Request、创建分支、 推送分支、删除分支、创建标签（里程碑）、创建 Wiki、添加仓库成员、强制推送分支、编辑仓库属性、可上传附件，可删除 自己或他人上传的附件、不能转移/清空/删除仓库

我们实际工程收住管理员角色人数，一般leader或者项目个别核心成员。其他的开发者、新人以及外包等都只能是开发者，测试人员等应该只是观察者。

规范之外：

人是最难管理的，以及人是懒惰的。这些话是非常准确的，所以会遇到以下问题，还得需要解决。

• 需求改动非常小，是不是还得走整体流程。
• 我只是修改文案，是不是还得走整体流程。
• 具体怎么做，每一个公司和组都有自己的做法，是不是都必须都得走一遍流程。但是，分支规范是必须的，不能随意修改。直接在主分支(master)和发布分支(RELEASE)修改，坚决说NO!