android项目有很多小团队，基于省事，在版本控制上很多都是简单粗暴，常常就是一个开发团队只有一个主干分支在同时进行开发、发版、修改bug工作，省事是省事，却也埋下一些隐患，假如线上版本出了一个紧急bug，而你正在进行新功能开发，怎么办？ 把代码备份回退先修改bug? 还是新拉个分支进行修改? 有什么策略？怎么控制代码质量？
下面我介绍一下我在我们团队实施的版本控制方法。
总体而言是基于git-flow的流程原则，即：
1、主干分支（master）永远可用
主干分支即线上版本的代码分支，必须保证绝对稳定可靠可用，新开分支是在主干分支基础上。
2、开发分支（develop）平时使用
在开发新功能或修改不太紧急的bug时都在开发分支上进行修改提交
3、紧急情况开临时分支
线上版本出现紧急bug，需要快速修复发版，在主干分支基础上开临时分支进行修复bug
4、临时增加一个小型功能开特性分支
产品经理应老板的要求，在短时间内需要上线一个新功能，那么可以在主干基础上开一个特性分支进行此功能的开发。
因基于保证主干分支稳定可靠的原则上，在其他分支写完代码后进行合并，可以使用pull request功能进行辅助迭代流程，使用pull request有以下好处：
1、组内成员可以互相进行代码review,发现代码风格或逻辑错误
2、配合jenkins的Merge验证，能减少因合并带来的代码风险。
下面我以gitlab为例，介绍具体流程如下：
在开发分支或其他临时分支开发完毕，在gitlab中发起pull request
发起完 pull request之后，组内成员都能看到这个pull request,
对这个pull request可以进行代码review（组内成员互相进行）,可以针对任意一行代码进行交流改进，并能提示此代码作者，以此来规范代码和提高代码质量，你们交流的信息都会在gitlab上留下记录，其他同事打开也能愉快的参与到讨论中来。
在检查完代码逻辑没有问题的情况下，准备合并到主干（线上）分支前，jenkins会帮助分析合入之后是否会产生错误
如图,发起pull request后，jenkins会自动触发工作，进行模拟代码合并，并进行打包及单元测试工作，同时向gitlab发起消息，告知是否成功，如果检测通过，可以在gitlab放心点击“Aceept Merge Request”，此段代码即会成功合入主干分支（免去以前还需要在本地进行合并测试再提交步骤）。
通过分支控制，及jenkins的对merge的预检测，整个流程下来，基本能很好的覆盖移动开发场景。
关于jenkins如何进行合入(pull request)预检测，以及如何利用jenkins进行版本发布，请看如下两篇：
