互联网创业公司基于Gitlab/Jenkins的项目版本管理方案
关于Gitlab
Gitlab是一个用于仓库管理系统的开源项目，使用Git作为代码管理工具，并在此基础上搭建起来的web服务。相比SVN，Git管理代码工具最大的优势是允许分支自由拉取、切换与合并。建立一个工程便可管理多个分支，且允许面向同一个产品的不同开发小组并行开发，互不干扰。
关于Jenkins
Jenkins是一个开源软件项目，是基于Java开发的一种持续集成的工具，用于监控持续重复的工作，旨在提供一个开放易用的软件平台，使软件的持续集成变成可能。Jenkins主要功能有两个，一个是持续自动的构建/测试软件项目，另一个是监控软件开放流程，快速定位处理问题。
关于创业公司局限性
其实网上已经有许多关于Git的项目版本管理方案，之所以还要写这篇博客，是因为许多方案要么是通识性的，要么仅适用于大公司，并没有一套针对创业型公司比较实用的方案。相比大公司，创业型公司有诸多局限，比如环境资源有限，测试团队有限，通常无法完美实现Git方案中的并行模式（并行一般意味着需要丰富的资源），而是采用串行+并行结合的方式实现较为高效的管理。本文将展现如何利用最少资源实现相对高效顺畅的Git管理，相信大部分创业型公司面临的都是类似情况。
Git管理方案
六大分支介绍
master
master分支为线上主分支，存放随时可以在生产环境中部署的代码。
该分支由运维人员维护，其他人只有拉取权限。
生命周期： 伴随着整个项目的周期，项目结束时结束。
develop
develop分支为开发主分支，所有其他分支修改过的记录全部要合入该分支，确保develop分支包含所有修改与新增的代码。转测时的bug修改在该分支进行。
该分支由开发人员维护。
生命周期： 伴随着整个项目的周期，项目结束时结束。
release
release分支为测试主分支，存放转测代码。转测分两种状态：通过与不通过。通过的话则将代码同步到master分支准备上线，不通过的话则反馈开发在develop分支上修复bug。
该分支由测试人员维护。
生命周期： 以转测开始，到生产上线结束。
注： 其他版本的管理方案会将bug修改安排在release分支上进行，而我们不采用这样的方案。一来因为release分支的代码是从develop同步过去，在develop上修改bug也是一样。二来我们认为分支的功能越单一，则管理越高效。release分支仅用于转测就足够了，减少了开发人员的分支维护数量。三来其他版本之所以选择在release分支上修改bug，是为了将develop分支腾出来可以合入新的分支代码。这种选择在有多组测试人员多个环境并行测试的情况下，的确能大大提高效率，快速迭代。但由于创业型公司的测试人数和环境限制，并不能达到并行测试的理想状态，所以我们在此处做了调整。
feature
featuren分支为迭代开发分支，负责产品主功能迭代。从develop分支拉取，开发完成后再合并回develop分支。
该分支由开发人员维护。
生命周期： 从一个新功能开始，到开发完成合入develop分支结束。
operation
operation分支是我们新增的一个概念，对应的是运营活动分支。其管理模式和feature分支差不多，但因为一些公司的开发团队和运营团队是分开的，运营活动和功能迭代也是交错进行，所以将该分支独立出来说明。该分支同样也是从develop分支拉取，开发完成后再合并回develop分支。
该分支由开发人员维护。
生命周期： 从一个新运营活动开始，到开发完成合入develop分支结束。
注： operation分支的开发最好是和featuren分支同步，一起转测。假如无法同时完成，根据优先级和完成时间安排先后转测上线。如果有特别紧急的运营活动，则通过hotfixes分支上线。
hotfixes
hotfixes分支为紧急修复分支，当线上出现严重问题或者有特别紧急的需求/运营活动上线，则直接从master分支单独拉取出来，在该分支修改、测试，然后上线并同步合入develop分支。
该分支由开发人员和测试人员共同维护。
生命周期： 问题出现到问题修复 / 新功能开始到上线
注： hotfixes分支对于所有人来说都是最高优先级。假如在转测期间出现了要拉hotfixes情况，则转测中止，测试环境需要转去测试hotfixes分支代码。测试通过后hotfixes分支的代码合入develop分支，再同步到release分支，重新开始测试。
资源背景
一组测试人员（串行测试）
2-3套部署环境（资源紧张的话测试和开发共一套环境，线上一套环境）
4套Jenkins配置（开发，测试，线上和hotfixes）
一组功能开发人员
一组运营活动开发人员
