分支管理

我们团队怎么做分支管理

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

分支管理一直是技术团队最基础的但是却最容易忽视的一块，每隔一段时间总会出一些因为代码管理不善造成的严重线上故障，究其原因，都是低级错误，为此，我们制定了代码分支管理规范。

分支命名

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

规范

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

常驻分支

• master 主分支， 应该永远处于稳定状态，该分支只能接受合并 RELEASE 分支代码，其它分支一律禁止直接提交或者合并到该分支，其他任何分支均从 master 分支创建。

• release 发布分支，该分支只能接受合并 DEV 分支代码，其它分支一律禁止直接提交或者合并到该分支，测试没问题以后合并到 master。

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

短期分支

新特性分支

新特性开发分支

中间有下划线，但是预览状态不显示！！！！

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

【例子】

DEV_20190716_代理费支付，代理费 20190716 版本的开发分支，根据年月日生成版本号。

DEV_20190716_代理费支付_小明 代理费 20190716 版本的开发分支，小明的本地分支，务必是姓名全拼（不用push到远程）。

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_20190716_代理费支付，如果有冲突，在 DEV_20190716_代理费支付分支解决冲突并且 push 到远程。
• 将 DEV_20190716_代理费支付分支代码合并到 SIT 分支

注意事项：

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

发布线上：

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

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

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

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

成员管理

仓库成员权限可以以下几种：

规范之外：

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

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

特别注意

要上线某个功能的时候，开发人员首先将 master 分支合并到开发分支，如果有冲突手动解决，然后提交拉取请求。

原则上 sit 测试分支只能给开发和测试人员测试， release 分支为预上线环境，开发、测试、用户可以进行测试。