聊聊移动客户端开发中的git工作流

2017-04-10 本文已影响281人码农苍耳

现在git已经是我们日常开发必备工具，那么在移动客户端的日常开发中，应该怎样去管理git分支呢，是否目前普遍的几种工作流就可以满足目前的情景呢？

git flow

最官方的流程，包含的主要分支有如下几个：

master 也就是发布分支
develop 也就是开发分支，上线的时候会把develop合并到master
feature 特性开发分支，每一个功能都会拉一个分支出去开发，完成后合并到develop，并删除自己
bug fix 日常的bug修复分支，这个是从master分支拉出来的，所以合并的时候要合到develop和master上，比较麻烦

按照以上说法，流程也是比较清晰明确，大致如下

            develop         master
              *              |
     ---------|              |
   /          |              |
  feature1    |              *        
  |           |              |
  *           |              *
  |           *             /|
  *         / |            / |
  |  feature2 |      bug-fix |
  *        |  |          |   |
  |        *  |          *   |
  |        *  |         / \  |
  |         \ * -------/   \ |
   \          *              *
    --------- *              |
              |\             |
              | \----------- *  release
              |              |

github flow 和 gitlab flow

git flow还是比较麻烦的，所以后来一些网站并没有推荐。

这两个工作流都是持续集成的模式，大致包含的分支如下：

master 主分支，但是作用相当于git flow里面的develop，github flow也是release的分支
feature 或者说 merge request
production 发布分支

功能分支和bug fix都是从主分支上拉出来改，再合并回去。流程上比git flow更加简单。

移动端现状

但是以上几种真的适合目前我们的开发吗？

首先来分析下git flow的应用场景。

linux这种大型项目，人员分布于世界各地，而每一次发布的功能又非常的多，为了保证所有人的协同工作不会出现任何偏差，所以他们采用了git flow这种工作流。

这类项目有着如下特点：

每一次发布的周期很长，而且其中的bug fix会以单独的小版本或者补丁形式发布出来
每一次发布所更新的功能并不是固定的，哪些feature完成了，才会考虑合并入系统，而没有完成的继续开发，会在下一次版本发布时再考虑
每个feature之间的关系比较独立，相互间不会产生很大的影响

linux为了解决自身庞大的系统的情况，在git flow外面再套了一层git flow，有着相当严格的代码审查制度，这个是后话了。可以看出如果是一个瀑布型开发场景，还是非常合适的，但是我们目前的移动开发几乎都是敏捷开发。

再来看看github flow和gitlab flow

他们自身是一个开放的交流平台，为了增进大家的交流，就必须加快和简化发布，时刻让主分支保持最新
为了给大家共同开发提供条件，发明了merge request，如果被采纳，需要尽快的合并到主分支上
托管的项目大部分是小型项目，没有开发计划和排期要求，所以就很难有如此明确的版本，所以基本上是每个特性都会有一个发布，也就没有必要整一套严格的审查制度

这个比较适合网站这类的开发，当完成新特性后，马上就可以展示给用户，并不需要卡时间点。

目前状况

目前大家一般都是敏捷开发，最长一个月，最短2个星期就会有一个新版本
每一期的新特性多，但是功能点却非常细小，而且会有很多的优化
bug修改完以后一般不会立刻发小版本来专门修复bug，一般会在下一个版本中修复

所以git flow对于现在的情况来说太慢了，而且导致分支间切换太频繁。但是其他几种又不能很好的区分版本，所以我们需要自己的工作流程。

                              master
              ---------------- * 
            /                  |
          v1.0                 |
            |          ------- *
            *        /         |
          / |     bugfix       |
 feature-x  *       |          |
         |  *       *          |
         *  *      /           *
          \ * ----           / |
            *            v1.1  |
       test *              |   |
              \            |   |
                -----------+-- *  release
                           |   *
                           * / |
                      test *   |
                            \  |
                             - *  release

每个版本都从master上拉一个版本分支，此版本的所有改动都在这个分支上进行，此时这个分支就像是github flow的master，保持持续集成，如果功能点比较大，可以考虑在版本分支上拉功能分支进行开发。
bugfix一般直接修改在版本分支上，也可以从master上拉分支，最后合并到版本分支上，这样做是考虑到版本交替的时候可以方便处理bug。
测试和打包都在版本分支上，发布以后合并到master

这样看上去似乎比其他几个复杂，但是实践下来应该说更加简单。

我们很少存在并行开发的情况，所以每个版本几乎都是串行排列的，很少出现交叉的情况
我们的功能点很小的时候没有必要拉一个新的分支，可以直接修改到版本分支上，不需要专人合并
feture分支一般为个人开发分支，一个人来维护合并和删除，也会简单很多
这样每个版本的代码分支完全独立开来，更直观的区分不同版本间的代码进度
减少了日常工作中需要频繁切换分支的状况
可以让CI系统直接对接版本分支，大家可以第一时间得到该版本的最新包

所以正常的使用中，可见的分支为master和版本分支，会比上图简单很多。

但是这样做的缺点是无法明确的区分feature，如果需要去掉某一个功能的时候会比较麻烦，基于每次的迭代都是相对明确，不太可能出现功能回退的情况，所以不存在这种问题。

总的来说，适合的才是最好的。