在团队中使用GitLab中的Merge Request工做模式

在工做中使用Git已有5年多的时间了，Git分布式的工做机制以及强大的分支功能使得在团队中推广使用没有受到什么阻碍。一直以来都是采用的分支管理模式，我把项目的开发分为三个阶段：开发、测试和上线。

1、分支管理模式

一、开发阶段

1. 除了master分支建立一个供全部开发人员开发的dev分支；

    

2. 开发人员在dev分支上进行工做，随时随地commit，天天push一次到服务器；

3. push代码前须要进行pull操做，由于有可能在以前有别的成员先进行了push操做，若是有冲突还须要进行冲突解决；

4. 天天上班后全部成员对dev进行pull操做，获取全部成员push的代码，有冲突须要解决；

5. 团队Leader天天将dev合并一次到master。

二、测试阶段

1. 测试进入后就须要添加test分支；

2. 在开发人员将代码push到dev分支后，能够在dev基础上建立test分支，测试人员以test分支搭建测试环境，开始测试；

3. 开发人员在接受到bug后，直接在测试分支上修改，而后让测试人员进行验证；

4. 天天团队Leader将测试分支上修改的bug合并到dev分支上，这样全部团队成员当天修复的bug都会在次日被团队其余人pull下来；

5. 团队Leader天天将dev合并一次到master。

三、上线阶段

1. 系统上线后试运行阶段会存在两种改动：bug和优化需求，bug一般当天解决晚上部署，优化需求一般周末部署；

2. bug当天能修复的就直接在test分支上修复，而后进行测试，验证经过后合并到master；

3. bug当天不能修复的就针对该bug建立一个分支，修复完后合并到test分支进行测试，验证经过后合并到master；

4. 每一个优化需求都以master分支为基础建立一个feature分支，完成后合并到dev分支，开发人员能够先交叉测试，而后将dev合并到test进行测试，验证经过后合并到master；

5. master始终是一个干净的，可发布的分支。

2、Merge Request模式

一直以来，都以为Merge Request模式高不可攀，只有作开源软件才会采用这种模式，没想到这么快就已经在团队中开始推行使用了，先看一张图来了解下Merge Request的开发流程：

1. 需求或是Bug都是用Issue来表示；

    

2. 虽然Issue不支持多层级，但结合里程碑、标签等仍是能够很好的对任务和Bug进行管理；

3. 管理员和团队成员均可以进行Issue的建立；

4. 任务的接收者对Issue建立Merge Request；

5. 完成任务后推送代码到Merge Request对应的分支；

6. 管理员对代码进行Merge。

相比较传统的分支管理模式，Merge Request能够给咱们带来下面几个好处：

1. 重要分支设置为受保护，杜绝了有些问题代码被提交了，但项目经理不知道的状况；

    

2. 每一个任务都有一个对应的分支，互相隔离，全部的代码改动有据可查；

3. 开发人员不用在分支间切换和合并，更专一于开发。

下面以一个示例来介绍Merge Request的工做流程

一、设置重要分支受保护

在上图中的位置能够将全部的重要分支设置为受保护，重要的分支一般是master、release、test等。

二、建立Issue

任务建立后，开发人员就能够对该任务建立Merge Request了，以下图：

• 建立Merge Request时会建立针对这个任务对一个分支；
• 分支名称的格式为：任务编号-[任务标题中出现的英文和数字]，固然分支名称也能够自行修改；
• 分支的Source为该项目设置的主分支，主分支能够在设置/General/General project settings/Default Branch进行设置。

三、使用你熟悉的工具拉取Merge Request对应的分支到本地进行代码修改，修改完成后，Push代码到服务器，代码推送后，管理员在Merge Request页面能够看到Merge按钮，以下图：

点击右边的Resole WIP status后，Merge按钮就可使用

若是勾选Remove source brance，当Merge后，服务器端会删除建立的分支。Merge完成，会关闭关联的任务，但并非每一次推送均可以很是顺利，有时会有冲突，当本地代码和服务器代码不一致时，会出现解决冲突的按钮，解决冲突后才能进行Merge

代码Merge后，开发人员就能够按照一样的流程作下一个任务了。

3、思考

• 若是系统上线后有紧急Bug须要处理，这个流程应该怎样去调整？
• 每一个任务都在单独分支并行开发，这是若是A和B都以来C开发的一个模块，应该怎么解决？
• 理论上Issue管理员和开发人员均可以进行建立，什么样的Issue能够有开发人员来建立？

4、总结

• 任何一种模式或工做方式的改变，总会打破一些人的温馨区，咱们应该学会走出温馨区，拥抱变化；
• 尝试新的东西确定会遇到各类问题，先执行，而后再持续优化改进，逐步达到最优状态；
• 从团队试用的状况来看，暂时没有出现水土不服的状况。

原文出处：fwhyy -> http://www.fwhyy.com/2018/06/Use-the-Merge-Request-working-mode-in-GitLab-in-the-team/