Git 的一大特点就是可以创建很多分支并行开发。正因为它的灵活性，团队中如果没有一个成熟的分支模型的话，那将会是一团糟。

分支模型

有个比较成熟的分支模型git flow。需要注意的是，它只是一个模型，而不是一个工具；你可以用工具去应用这个模型，也可以用最朴实的命令行。所以，重要的是理解概念，不要执着于实行的手段。

简单理解几个概念：

「master」和「develop」是主要分支，其他分支是派生而来的。各类型分支之间的关系用一张图来体现

开发流程

1.开发接收需求，切换到develop分支，pull develop分支最新代码，拉取特性分支feature；

2.每一个新功能的开发都应该各自使用独立的feature分支。为了备份或便于团队之间的合作，这种分支也可以被推送到中央仓库，B和A可以同时在一个特性分支上协作。

3.功能开发完毕并且自测后，先切换到 develop分支，pull最新代码，切回功能所在的feature，把develop分支的代码合并进来，有冲突和配合的人一起解决。

4.到 GitLab 上的项目首页创建feature合并到develop的合并请求（merge request），比对和上个版本的代码变化，指定有合并的和参与代码审核的同事。（代码审核）

5.项目负责人在收到合并请求时，应该先做下代码审核看看有没有明显的严重的错误；有问题就找负责开发的人去修改，没有就接受请求并删除对应的 feature 分支。

有问题的代码开发者自己修改后在push到仓库，代码审核页面会同步最新修改。

6.负责测试的人从develop创建一个 release 分支部署到测试环境进行测试，若发现了 bug，相应的开发人员就在 release 分支上或者基于 release 分支创建一个分支进行修复。

7.当确保某次发布的功能可以发布时，负责发布的人将 release 分支合并进 master 和 develop 并打上 tag，然后打包发布到线上环境。

流程图如下：

实际开发中会有几个问题：

1.同时维护master和develop两个分支很耗时，每次release分支发完版都要同步回master&develop；

2.功能并行开发时，无法及时同步上线和测试节点；

某个业务方的测试现在需要测试，但是不再这个版本，就无法操作。因为release分支是从develop上拉取的，同一个节点不能合并不再本期发版计划的代码step[5]

测试环境也只能同时发布一个分支step[6]

3.审核代码后再次修改审核。step[6]&step[4]

我们简单的维护两个主要分支，不再维护release分支。

master -- 功能最稳定，线上正在运行，可随时发版，受保护的分支。

develop(test) -- 是功能最新最全的分支，也是部署在测试环境的分支，在我们这也可以部署在debug环境。

优化后的开发流程：

1.开发者pull master最新代码，拉取feature分支统一命名风格：feature_seckillCoupon_denghuanqing_20181223

2.在feature分支上完成开发自测后，切换到test分支，pull最新代码，把feature分支合并到test分支，可能会出现冲突，和协作同事商量解决。

注意，非简单的解决featue a 和test分支冲突，需要商量是feature a还是feature b需要调整代码，假若feature a需要调整代码，feature a调整代码，合并到test分支。feature b 重新操作合并到test分支。

3.通知测试在测试分支测试，这个阶段不用关心发版进程，除非业务互相依赖。bug也在feature分支修改，修复完成后合并流程参考step2;

4.测试完全通过后，开发切换到master分支，pull最新代码，切换回feature分支，把master分支合并到feature分支（保证即将发布的代码没冲突），在gitlab提交合并请求，写上功能需求点，脚本等，指定项目管理员审核并且合并代码。

5.管理员审核代码，处理（本次版本内）合并请求，打tag，发版，走线上验证流程。

6.完成功能开发。feature可以保留几周后统一清理，我时常会在功能分支上找一些写过的代码。

7.备注:修改线上的bug重新从master拉去分支或者使用未被污染的feature分支都ok。

1.保护分支

2.提交合并请求

项目首页点击下拉框

3.选择要把那个分支合并到master

4.填写本次发版相关描述，比对代码差异。确认提交后通知相关权限用户。（gitlab同时提供邮件通知）