现在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，如果需要去掉某一个功能的时候会比较麻烦，基于每次的迭代都是相对明确，不太可能出现功能回退的情况，所以不存在这种问题。
总的来说，适合的才是最好的。
