点击上方?Java编程技术乐园，轻松关注！及时获取有趣有料的技术文章

做一个积极的人

编码、改bug、提升自己

我有一个乐园，面向编程，春暖花开！

Git是一个非常强大的分布式版本管理工具，分布式简单的理解就是在本地也会copy一份代码数据，用户机器可以当作一台本地服务器，用于代码的离线的提交，即你坐在青海湖边在没网络的情况下也可以提交自己的代码，想想就流逼，但是真正提交到中央仓库还是需要网络才行，不过这个功能已经可以让大家不受中央集群的服务状态影响，即使挂掉了自己还可以进行代码提交，等服务器正常后再次提交即可，本文不讲述git与svn的区别，如果想大概了解的话可以查看《git与svn的区别》，下面主要讲述git分支管理在项目中的实际使用。

主要分为以下四大分支：

1.master

2.dev

3.test

4.bugfix(可不用)

一、master(主分支)

当代码克隆下来后默认就是这个分支，也就是所谓的主分支，可以认为该分支是存储当前功能测试通过且可运行的正式代码，所以一般不会直接在主分支上进行开发，这个是核心分支，也就是主路径，所有最后的代码都必须合并到主路径上，如果发布到生产环境必须通过master分支进行打包，这是代码管理非常重要的一步，即使线上代码出现问题后也可以迅速通过主分支进行代码修复，保证不会出错，也保证修复的是与线上正在的运行代码同步的。

	git clone xxxxxxxx.git 

master的版本管理直接用tag功能即可，即通过打tag的方式表示当前可以上线的一个版本，也方便以后进行对应版本的数据查询或者比较，如v1.0.0-publish,v2.0.0-publish等

二、dev(开发分支)

开发分支是研发同学最需要关心的，所有的开发工作应该围绕dev分支进行展开，创建dev分支脚本如下：

	git checkout -b dev master 

dev分支在实际工作中主要有两种常用场景：

1.单个版本开发

2.多个版本并行开发

针对第一种情况，属于比较常见的情况，即开发过程中都是按顺序进行的，即1.0.0开发完成之后才会进行开发1.1.0的需求开发，1.1.0完成上线后再进行1.2.0的版本开发，针对这种，工作直接在dev分支上开展就可以了，不需要做特殊处理，因为不会产生任何干扰~~

相关操作脚本：

	git checkout -b dev master 

针对第二种情况，可能在互联网公司会比较常见，在开发资源比较充足的情况下，多个版本可能同时并行，即1.1.0和1.2.0或者更多版本在同时开发，但是又想快速试水一些功能，不可能等到全部做完都上线，所以1.1.0会先发，1.2.0会在另外一个时间点发，产品经理通常会很着急，认为错过这个时间点就会损失十几亿的感觉，碎碎的忧伤，所以分支的合理管理非常重要，不然在开发过程中会显得非常混乱，如果都在dev分支上进行开发就会把没做完的功能都发线上了，这时候就更碎了~~~ git 也给我们使用feature功能模式，即功能分支，可以通过这个来划分，如下：

先创建两个feature分支，跟创建dev分支一样，不过这次是从dev分支进行创建

	git checkout -b feature-1.1 dev 
git checkout -b feature-1.2 dev 

开发1.1.0版本操作的相关脚本：

	git checkout -b feature-1.1 dev 
git checkout -b feature-1.2 dev 

开发1.2.0版本操作的相关脚本：

	git checkout feature-1.2 
 
#又是各种commit push操作，开发完成测试通过后执行下面操作，合并代码到dev分支： 
git checkout dev 
git pull origin dev 
git merge --no-ff feature-1.2 
git push 
 
#删除本地feature分支 
git branch -d feature-1.2 
#删除远程feature分支 
git push origin --delete feature-1.2 

分支切换流程图如下：

三、test(测试分支)

测试分支很明显是给测试同学使用的，主要是开发同学认为在开发分支上进行测试通过后可以合并到test分支上，提给测试同学测试，如果需要简单一点的分支管理结构可以把test分支去除，因为加了一层之后合并的操作可能会增加，不过这块可以保证合并到主干的代码都是统一由测试同学测试通过后合并，因为dev分支一直都可以添加新代码，当增加新代码后必须要测试才可以上线，所以才会产生了test分支，创建分支的脚本如下：

	git checkout -b test master 

分支合并操作跟上面的操作脚本相似，这里面就不一一列出了，大概的执行路径如下图：

四、bugfix分支(bug修复分支)【可不用】

紧急修复线上bug的时候使用，但是一般场景的话直接在master上修复即可了，因为bug一般都是要立即解决，切个分支来做还会增加成本，所以可以不用单独切个分支出来，如果要使用的话其实也是从master上打个分支出来，修复完后直接合并到master上，分支创建脚本如下：

	git checkout -b bugfix master 

具体切换流程如下：

现在在项目中主要是使用dev - test -master的模式，大家也可以使用这种方式进行分支管理，让你的代码库更加有序，上面有说的不对或者写错的地方，麻烦大家在评论中指出，或者有更好的管理方法也可以一起交流~~~

作者:揸沽神

原文地址：http://www.uml.org.cn/pzgl/201608291.asp

Java编程技术乐园：一个分享编程知识。跟着老司机一起学习干货技术知识，每天进步一点点，让小的积累，带来大的改变！

持续推送有趣有料的技术文章~如果觉得文章对你有收获，点个赞呗！