我们团队怎么做分支管理
- 合并代码将别人代码合丢了
- 发布了并不计划上线的代码
- 代码分支非常多
- 长期在一个分支上开发
- 多人共用一个分支开发
- 每次提交代码都有冲突
- 不知道别人分支做什么用的
分支管理一直是技术团队最基础的但是却最容易忽视的一块,如果你团队中也遇到上述的问题,那么,建议你可以看看我们是怎么解决这些问题的。
我们团队近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!