Git--代码管理操作规范

前言

Git帮助我们更好地版本控制，团队协作过程中我们需要一套严谨的Git 操作流程规范来保证面对各种情况能保证代码的版本控制,不能为了一时偷懒随性提交、合并代码。随意提交、合并代码很有可能导致代码丢失、混乱一系列不可挽回的后果。本文是相关一套Git流程操作，能帮助我们更好地进行代码管理。其中有什么需要改进的地方，我们一起来沟通优化。

正文

一、分支介绍

流程图

master: 主分支，常驻分支，master代码与线上代码保持一致，只能合并“developer"分支中的代码，不能直接操作，也不能合并其他分支。

developer: 开发主分支，常驻分支, 代码上线后合并到"master"分支。

fix: 修复分支，开发完毕需要删除，用于不在版本计划中的bug修复。

dev_x_x_x：版本开发分支，开发完毕需要删除，根据版本计划进行开始的分支，可多版本分支并行开发。

feature：功能开发分支，开发完毕需要删除，同个版本中多个模块进行开发时，可从"dev_x_x_x"分支中拉出多个"feature",对应相应的模块进行并行开发。

二、开发流程

可以参照上面的流程图：

1、master -> ```developer`` 分支

如果没有developer分支，从master拉出一个developer分支。

2、developer-> dev_x_x_x 分支

从developer分支开出一个与版本需求对应的dev_x_x_x分支，开发完成后合并回developer分支，可以多个版本进行并行开发。

3、dev_x_x_x->feature分支

建议根据版本需求中的每个功能点，从dev_x_x_x分支拉出相对应的feature分支，开发完成后合并回dev_x_x_x分支。这样可以更加灵活地应对各种情况，例如： 开发过程中，项目需要提前上线，砍掉一些功能点，这个时候可以只合并需要的功能点。

4、fix分支修复bug

如果是需要发布一个紧急版本修复线上bug，从developer分支直接拉出一个fix分支进行修复，修复完毕后将需要将fix合并到developer分支后还需将developer分支合并进```dev_x_x_x``分支,保持开发分支的代码同步；

如果是非紧急bug，可以跟随正在开发的版本发布，从dev_x_x_x分支拉出一个fix分支，与``feature```分支并行。

三、合并时间点

1、功能点自测完毕

feature分支和非紧急修复fix分支，在开发人员自测完后合并到dev_x_x_x分支；

2、提测

版本提测的时候，将dev_x_x_x分支所对应的所有feature分支和fix分支合并回dev_x_x_x分支后，将dev_x_x_x分支代码打包提测。

3、测试过程中

提测后，测试人员测试过程中，发现bug需要修复，从dev_x_x_x分支上开出fix分支修复bug，修复完合并回dev_x_x_x分支。
如果期间有紧急fix分支合并到developer分支，需要将developer分支合并进dev_x_x_x分支进行测试。

4、测试完毕

dev_x_x_x分支测试完毕封包后，将dev_x_x_x合并回developer分支，将developer分支打包准备上线，封包后有改动走紧急"fix"分支。

5、正式上线后

版本正式上线后将developer分支合并到master上。

四、注意点

1、除了master分支和developer分支保持不删之外，其他相关分支开发完毕应及时删除避免造成开发分支数量过多带来管理混乱。
2、master分支的修改只能从developer分支合并，不能直接进行操作，或者从其他分支合并。
3、紧急fix分支合并到developer分支后，需要将developer分支合并进dev_x_x_x分支