我学习git的一种流程策略

git很方便,相比于svn,git这种分布式的版本控制系统能够快速切换分支,可以非常快的切分支,这样就能够保证实现“团队中的大家拉自己的分支去开发,开发完成后合并到远程的开发分支”这种开发模式。正是由于这种方便,很容易就把分支给整乱了(特别是团队中有我这种菜鸡随意提交随意合并的情况下),经常出现分支树很混乱的情况。
所以,需要设定一些规矩,一些策略来约束开发者来进行合理的使用git。
经过我的调研,主流的git工作流程策略有以下几种:Git flow, Github flow, Gitlab flow,这些都是针对功能驱动开发的模式来做的流程策略。

Git flow

2010年的时候,Vincent Driessen发布了他针对git所作的一个分支模型 A successful Git branching model。之后又发布了这一模型的实现,Github地址 https://github.com/nvie/gitflow
使用gitflow,就会天然的遵守gitflow的流程规范。这里就不再讨论gitflow这东西怎么用,只是调研下它的特点。

git flow

主要分支

  • master分支
  • develop分支

develop分支用于开发,而master分支用于长期和生产环境严格一致,随时可以打包master分支部署到生产环境,因此很多时候master分支是锁定的,只有项目特定的人有权更改和合并。

短期分支
短期分支不是必须的,但是在实际使用中一定会用得到,主要包含了以下几种

  • 功能分支Feature branches
  • 发布分支Release branches
  • 补丁分支Hotfix branches

功能分支Feature branches是在develop分支上拉出来的,用来开发新功能,例如当订单模块的需求开发时,可以新建分支feature-order来开发,开完完成后合并到develop。
发布分支Release branches是在develop分支上拉出来的,当develop分支开发测试完成之后,准备上线的时候,会把develop分支拉一个分支准备上线。例如release-2.1.2。上线完成后会把这个分支合并到master分支去,假如上线失败了(我还没碰到过这种情况),发现了严重问题,马上暂停release分支的部署,从master分支进行打包部署,恢复生产环境的正常问题。
补丁分支Hotfix branches是在master分支上拉出来的,当上线完成后,突然发现了一个bug,这时候就需要快点把问题修复,需要上一个临时版本或者一个紧急修复包,这时develop分支已经开发了若干下一版本的内容,因此需要从master分支拉出一个快速修复分支Hotfix branches,开发测试完成后,需要合并到Release分支和develop分支,然后上线完成,再把Release分支合并到master。

Git flow的优点非常明显,各个分支各司其职,单个分支来说清晰可控,但是那么多个分支真的比较复杂,开发的时候需要多次切换分支。并且对于现在“持续发布”的模式,需要不停的变动,不停的部署,这样就要求develop分支的代码不停的合并到master,这样master和develop几乎就一样的,没有必要同时整这两个一样的分支。所以后面就又出现了更为合适的流程策略。

Github flow

为了免去Git flow学习成本高,用起来太麻烦这个问题,Github出了自己的流程策略 GitHub flow
Github flow有一个master分支和n个其它分支,这看起来就超级简单。例如我要开发订单功能,我就可以从master拉一个分支为order,然后在order上开发,开发完成后,发起一个PullRequests,找人review我的order代码,讨论问题,通过之后,进行发布,发布成功之后就可以合并到master。
很明显,这个超级简单,优先限保证了持续部署,但是部署的时候需要不停的分支切来切去(前期的Github流程没有部署这一步,会直接打到master中再进行打包,这也会带来很多问题),倘若有多个版本要部署的时候,代码很容易就会乱掉。太简单也并不是最合适的。

Gitlab flow

复杂的太难,简单的又有一些缺陷,为此Gitlab提出了一个比较折中的方案。Master分支和Github的处理一样,从功能分支使劲的合并,合并完之后,合并完部署,然后在进行测试。
就这样,我们可以建立三个分支分别对应三个不同的环境。

  • master分支 —-> 本地测试环境
  • pre-production分支 —-> 外网测试(预发布)环境
  • production分支 —-> 生产环境

本地测试环境开发然后测试通过之后,部署到外网测试环境,才可以合并到pre-production分支;外网测试环境测试通过之后,才可以合并到production分支。Gitlab flow规定了一个“上游(upstream)”的概念,意思就是master是pre-production的上游,pre-production是production的上游。
这种模式看起来很好,既能够支持快速发布的持续发布,又能够支持传统的按照版本发布的模式,但是这种“上游优先”规定,导致了生产出bug的时候,需要一步步的从上游往下游合并代码,也是比较复杂的。

适合自己的才是最好的

我目前所在的团队没有持续发布,并且我们是按照版本发布的,照这样说,好像git flow最适合我们团队,然而没人用过git flow(可能有人用过,但是他不知道他用过,也是个二把刀),所以我们经过讨论加上综合了以上几种工作策略,最终设定了目前适合我们团队自己的策略。

  • dev分支,长期分支,开发环境使用该分支。
  • prod分支,长期分支,该分支是在上线前准备,dev分支合并到prod分支,使用prod分支部署到生产环境,上线完成后prod分支合并至master,上线出现事故时,马上使用master分支回滚生产环境(这个分支存在的目的就是为了防止上线后马上发现了问题,需要回滚,这种情况极少,但需要预防)。
  • master分支,长期分支,prod分支部署完成后没问题的情况下,合并到该分支,该分支长期和生产环境严格一致,根据版本打tag。
  • 功能分支Feature branches,短期分支,从dev检出,开发完成后合并至dev。
  • 补丁分支Hotfix branches,短期分支,从master检出,开发完成后合并到dev分支进行测试,测试通过后,合并至prod分支。

相对于git flow,我们没有采用多个Release分支来进行保持版本和发布,而是采用一个独立的长期存在的prod分支进行发布。这样对于自动化打包部署,我们各个环境拉去的代码分别对应如下。

  • 开发环境 —-> dev分支
  • 测试环境 —-> dev分支
  • 生产环境(上线) —-> prod分支
  • 生产环境(回退) —-> master分支

以上就是我最近几天我在git上的思考和收获,以及我们团队目前在用的git工作流程策略,不一定对,但勉强能用。

ps.
最近研究git的这些东西是因为团队中新的小伙伴皮皮鲁,他期望团队的版本控制系统能从svn切到git中去,于是我就开始安装部署,我一开始安装了gitlab,但是很无奈,gitlab实在太耗内存了,之后我找到了轻量级的 gogs,虽然功能差了不少,但是仍然很好用。
团队中加入新鲜血液真的超级棒啊,感谢同事们带来的帮助。

0%