Git详解

1、分支管理组成

1.1、master主干

在版本管理中，代码库应该仅有一个主干。此主干是和当前生产保持一致的，是可用的、稳定的可直接发布的版本，不能再主干上进行任何开发操作。git主干的名字，默认叫做 master，它是自动建立的。

1.2、develop主开发分支

因为不能在主干master上进行开发，那么就需要在基于主干master的基础上，创建一个开发主分支develop，开发主分支develop的代码永远是最新的，所有的新功能都是以此分支为基础进行开发的，该分支只是做合并操作，也不能在此分支进行实际开发。

1.3、feature功能开发分支

功能开发分支，在develop上创建分支，采用“feature-” +“分支创建时间”+ “批次名称-”的命名规范。
例如：“feature-20190301-XXX”
此分支既作为需求开发分支又作为需求测试分支，所有需上线内容需在当前分支充分测试通过后，才可提交test分支与其他待上线分支代码进行合并，然后进行test分支回归测试。

1.4、test测试分支

test分支它是指发布正式版本之前（即合并到 master分支之前），我们需要有一个预发布的版本进行测试。
预发布分支是从develop分支上面分出来的，预发布部署生产验证无误，结束以后，必须向下合并进 master和develop分支以及develop衍生所有开发分支，保证各分支基线版本与生产基线同步。

1.5、hotfix紧急bug分支

项目上线后会遇到一些需要紧急修复的bug，那么就需要创建一个紧急bug修改分支，此分支需要从master直接拉取分支进行开发修改，修复完成后必须向下合并进 master和develop分支以及develop衍生所有分支，保证各分支基线版本与生产基线同步。
采用
“hotfix-” +“分支创建时间”+“bug号或bug描述”的命名规范。
例如：“hotfix-20190116-001”

2、分支使用流程

具体使用步骤如下：

2.1、开发关联需求

关联需求：A和B同时开发一个需求内容，A所开发的内容有部分是基于B开发的内容。
在这里插入图片描述
上图为关联需求的开发及测试流程图，以下为每个节点的介绍：
①　从master主干的基础上拉取develop分支作为开发分支
②　从develop分支的基础上拉取test分支作为测试分支
③　从develop分支的基础上拉取feature分支作为开发分支
④　在feature开发分支进行需求的开发
⑤　将并行的需求feature分支单独测试，然后合并到test测试分支进行上线测试操作

在这里插入图片描述
上图为关联需求的上线前后流程图，以下为每个节点的介绍：
①　在test分支测试通过
②　将feature2的开发分支合并到feature1的开发分支中
③　将合并后的feature1分支的内容合并到test分支回归测试
④　test分支回归测试完成，用master分支合并test分支上线
⑤　将master分支向下合并到develop分支及其他正在开发中分支

下图为关联需求分支的整体流程图：
在这里插入图片描述

2.2、开发独立需求

独立需求：A和B同时开发两个完全不相关的需求内容。
在这里插入图片描述
上图为独立需求的完整流程图，以下为每个节点的介绍：

①　从master主干的基础上拉取develop分支作为开发分支
②　从develop分支的基础上拉取test分支作为测试分支
③　从develop分支的基础上拉取feature分支作为开发分支
④　在feature开发分支进行需求的开发
⑤　对feature分支的内容进行测试
⑥　feature1分支测试通过后，将合并后的feature1分支的内容合并到test分支进行预上线测试
⑦　测试通过后，将test分支合并到master主干上线
⑧　将master主干合并到develop分支中，保持master主干和develop分支内容一致
⑨　将develop分支合并到feature2中，保证feature2分支已经包含已上线的feature1内容

2.3、修复生产bug

在这里插入图片描述

①　在master主干根据命名规范创建hotfix分支
②　hotfix分支内容修改并测试
③　hotfix分支测试通过后合并master主干上线
④　将master主干的内容合并到develop和test分支，保证develop分支内容与主干分支同步，从而保证与生产环境同步
⑤　将develop分支内容合并到test分支，保证test分支与主干同步
⑥　将test分支的内容合并到feature分支，保证feature包含hotfix分的内容
⑦　feature分支继续开发

3、注意事项

一个分支尽量开发一个批次，不要多个功能模块在一个分支上开发。
每次commit时，一定要把注释写明
开发过程中如果人员A开发的功能依赖于人员B开发的功能，可以在组员B的分支直接创建一个基于人员B的为主干的分支
每次合并时，先将需要被合并的分支pull一下，看看有没有冲突，如果有先解决冲突后再合并
本地分支切换的时候（例如A切到B），会弹出来Restore workspace on branch switching 对话框，如果选择是的话，在切换分支的时候，你在当前分支（A）所做的一些还未add或commit/push的文件改动（包括断点等的设置）会带到切换后的分支（B）上
如果本地工作空间（分支A）有些文件会被分支B改动，IDEA会弹出对话框，让你选择Force Checkout 或 Smart Checkout;
 如果选择Force Checkout，本地工作空间（分支A）的一些未提交的修改会被覆盖（被分支B覆盖），会有很大可能丢代码！！
 如果选择Smart Checkout，IDEA会先执行stash命令，贮存这些未提交的修改，然后checkout 到分支B，在切换到分支B后，unstash 这些修改，所以A分支本地的这些修改会带到B分支上

Git详解及版本控制规范