android审核代码,android如何进行版本迭代及代码审核

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会帮助分析合入之后是否会产生错误

图中的 Build finished. Test passed等消息都由jenkins发来

如图,发起pull request后，jenkins会自动触发工作，进行模拟代码合并，并进行打包及单元测试工作，同时向gitlab发起消息，告知是否成功，如果检测通过，可以在gitlab放心点击“Aceept Merge Request”，此段代码即会成功合入主干分支(免去以前还需要在本地进行合并测试再提交步骤)。

jenkins的自动检测pull request job

通过分支控制，及jenkins的对merge的预检测，整个流程下来，基本能很好的覆盖移动开发场景。

关于jenkins如何进行合入(pull request)预检测，以及如何利用jenkins进行版本发布，请看如下两篇：