阅读 77

git多种工作流比较与应用场景

前言

        git作为当前普及率很高的代码版本管理工具,在工作和个人使用中有多种工作流方式,不同的工作流也对应着不同的使用场景,因此笔者在这里总结一下使用git以来遇到的多种使用方式。

分布式版本控制系统

        开始之前,我觉得我们要对git的基本概念有所了解,git在本质上是一种分布式版本控制系统,而对应的svn则是集中式的版本控制系统。如下图所示:集中式的svn除了对于SVN服务器上部署代码仓库之外,其他所有协同工作的伙伴都是一个对应的文件副本,没有仓库的全部信息,即伙伴们同步信息只能通过SVN的中央仓库,而一旦中央仓库除出了问题,就只能等待修复完成后才能提交和同步代码。

        与之对应的分布式版本控制系统git则不然,我们每个伙伴执行了git clone操作的本地仓库都是一个版本库,相对来说去除了中央仓库这个概念,而对应我们搭建的远程仓库一旦出了问题,我们依旧可以在本地进行维护和对文件版本的维护,甚至我们可以这样做,两个伙伴如果是在同一网段下,还可以将对方的仓库当做中央仓库去同步数据。 图片名称

正文

        接下来就来说一下关于在使用git时遇到的多种工作流方式。分别是类似于SVN的集中式工作流、git flow工作流、fork pull request工作流。

集中式

        集中式如下图所示,有点类似于SVN操作方式的工作流,所有的伙伴都只在master分支上维护代码,适用于团队和产品都比较小的情况,或者是个人项目,比如自己的demo项目等,可以以较低的学习成本完成对git的使用,但无法利用其它特性优化项目代码管理。         集中式经常使用到的命令:

git clone  
git pull origin
git push origin
复制代码
图片名称

git flow

        git flow方式是我在工作中见过大多数团队在使用的git工作流,适合,如下图所示,git flow支持在以远程中央仓库origin master分支为基准的基础之下可以并行有多个分支,如我们的灰度分支(release)、仿真环境分支(test)、每个版本特性对应并行开发的feature分支。每个人可以操作不同的分支,很好的利用了git的分支特性,实现了不同环境的隔离,而且可以有筛选的将版本对应及测试通过的代码合并至mater主分支,在git flow工作流中,我们经常用到:

git clone
git push
git pull
git merge
git checkout
复制代码
图片名称

git fork pull request

        基于fork仓库的git工作流,是我认为最为合理且安全实用的工作流方式,只是相对git flow来说操作比较麻烦。如下图所示,我们在git fork工作流中,基于中央远程仓库进行fork,fork出个人远程仓库并且会复制完整中央远程仓库,建立起关联关系,接着我们队自己的远程仓库进行clone到本地,进行持续的迭代开发。对于同步至中央仓库来说,相对git flow多了一次merge的操作,即我们每次推代码变动,都会将变化推送至自己的个人远程仓库,接着,在gitlab或github等网页上发起一次合并请求:从自己的个人远程仓库feature分支合并至中央远程仓库的feature分支,最终手动接收此次merge request完成代码合并。相对于git flow多出了一次在网页上操作的手动merge。

        git fork式的工作流也常见于各种开源项目中,比如github中大型开源项目的贡献代码方式,并且在工作中使用git fork式的操作,也能够增加对于git操作的容错性,比如我们push代码到了错误的分支,这时只是我们自己的个人远程仓库受到了影响,公用的远程仓库没有受到影响,我们可以在自己仓库中进行错误修复等操作,时刻保持中央远程的正确性。在git flow工作流中,我们经常用到:

fork 
git clone 
git add upstream XX.git  //添加中央远程仓库为upstream的命名
git fetch upstream       //获取中央远程仓库最近的更新
git rebase upstream/feature1  //使用rebase变基同步合并中央远程仓库对应feature1分支代码
git push origin/feature1  //推送代码变动至个人远程仓库
复制代码

图片名称

总结

        总结一下,这篇针对当前遇到的3中主要的git工作流进行了分析,其中每种都有自己的实用场景和优劣势:

  1. 集中式:适合小团队简单产品迭代;
  2. git flow:适合较大团队,复杂场景及较多环境的产品迭代,合理利用了git 分支优势;
  3. git fork:适合较大团队,开源项目或公司中央仓库要求高质量,操作相对复杂。

        总之,就是如果在工作中,如果我们对自己的操作足够自信及犯错后可短时间内完美解决,完全可以使用git flow,在利用分支特性的同时也有较高的git操作效率;否则git fork是一个不错的选择。