如何利用分支管理更好地保护代码

Git 之前,版本控制和代码管理是 CVS 和 SVN 的天下,那时候我们觉得这个领域也就那样了,还能玩出什么花样呢?结果我们忽略了 Linus 这个神仙一般的人物。

2002 年,Linux 内核开发团队开始采用 BitKepper 作为代码版本管理工具。BitKeeper 是一套分布式的版本管理工具,它满足了 Linux 内核开发的技术需求。但是 BitKeeper 只是暂时对 Linux 等开源软件团队免费,并不是自由软件。2005年 BitMover 公司不再免费赞助 Linux 开发团队。对此 Linus 表示非常遗憾,但遗憾之后他并没有自怨自艾,而是愤怒的与其他几个小伙伴花了几个星期完成了一套新的分布式代码管理工具,命名为 Git。两个月之后,Git 发布了官方版本,并在不同的项目中开始应用,自由软件社区给予了 Git 广泛的支持。

与 SVN 和 CVS 等软件不同的是,Git 更关注文件的整体性是否有改变,Git 更像一个文件系统,它允许开发者在本地获取各种数据,而不是随时都需要连接服务器。Git 的最大的特点就是离线分布式代码管理,速度飞快,适合管理大型项目,难以置信的非线性分支管理。

2005 年 Git 发布之后,技术日臻成熟,很多大公司都开始采用 Git 管理自己的项目代码,对于 Git 的成功,Linus 表示:

Git的设计其实很简单,它有一个稳定而合理的数据结构。事实上,我强烈建议围绕着数据来设计代码,而不是反其道而行之,我觉得这可能就是 Git 如此成功的原因。坏程序员总是担心他们的代码,而优秀的程序员则会担心数据结构和它们之间的关系。

13年的时候,Jenkins 项目的一位开发者在推送更改时,意外地使用了强制推送,造成该项目在Github 上的代码库中 1 个月的提交被抹掉。该项目的社区成员很快反应过来,并且将该问题修复,但是这突显出当此类问题发生时,Github 的开放性(以及Jenkins 项目的开放性:允许任意用户提交代码到代码仓库)可能将问题放大。

Git 的强制推送命令:git push –force 告诉服务器用自己当前提交的分支引用替换服务器代码仓库中的指定分支引用。正常情况下,Git 仓库只允许 fast forward 的推送,它的意思是,当前代码仓库的引用是推送引用的祖先。但是强制推送却没有这个限制,它允许将引用直接修改到以前的版本。

实际开发中,一个仓库通常会存在两条分支:master 和 develop 分支,这个两个分支可以被视为是一个项目开发周期的缩影,两条分支都会随着项目的进度而不断的增加代码,其中master是自动生成的,develop则是由我们自己建立的。两者之间的关系如下图:

图片

  • master:master分支是整个仓库中所有分支中最稳定的分支,同时是可发布到生产环境的版本。
  • develop分支是开发分支,可能会有大量小规模的更新,每次发生更新时可以基于develop分支再创建一个新的分支,如feature/201901,当完成更新后合并进入develop分支并删除feature/201901。

图片

结合两张图来看,其实不难看出来两者之间的关系。这种模式也是一种比较好而且是比较成熟的模式,作为管理人员需要着重管理master分支和仔细审核每一次的合并请求。

图片

在 CODING 企业版中每个项目都是支持对分支设置保护功能的,设置保护分支后,除了管理员外其它成员都不允许向该分支推送代码,正常情况下我们会将主分支(master)设为保护分支或者将重要的设置设置为保护分支。开启保护分支后,该分支在分支列表中将以绿色盾牌为标志。

成员应当也是必须在develop及它衍生的feature分支上进行开发,开发完成一个阶段的版本并且测试通过后再将它通过合并请求的方式推送到master分支并邀请其他成员评审代码。 其他成员「允许合并」后可自行合并分支。

合并分支是Git中一个非常强大而且好用的功能,而通过对分支、合并分支的管理可以有效地杜绝强制推送等难以被恢复和解决的问题。整个流程如下图所示:

图片

CODING 企业版还支持对不同分支设置不同的管理员。当成员提交了分支合并请求时,理论上分支管理员应该对提交的代码进行严格审查,所幸 CODING 企业版中也已经附带了相关的功能。

图片

绿色代表这次提交记录新增的,红色代表删除的。管理人员可以直观的看到MR的情况,并且可以针对具体的某一行进行评论和审核。当管理人员仔细审查完确认没问题后可以将这个MR合并到master分支上。

当要发布到生产环境时,可以生成一个release或者是打上tag。

图片

这个时候问题就来了,假设生产环境下出现了需要紧急修复的问题,但这个时候develop中已经超过了master分支该怎么办呢?

我们假设master和develop分支中都存在同样的bug,那我们可以基于master分支上新建一个hotfixes分支,在hotfixes分支中修复好后将这个分支分别与master和develop分支进行合并。master分支在修复完成后打上新的tag,形成新的版本。

图片

Git分支十分强大,在团队开发中应该充分应用。一般在团队中多人开发模式下,要记得每次工作开始前最好先进行git pull更新到最新,以免发生本地与远端不同步的问题。通过分支管理规范了整个软件的开发流程。分支之间的互不影响这种特性可以增加团队合作的效率。

相关文章