一、前言
本文用实例来讲解Git的分支管理在产品快速迭代开发过程中解决实际问题的详细方案，面向的是对Git有一定了解的朋友（多图预警）。
二、背景
最近接手了一个代码质量惨不忍睹的项目，立即着手进行重构，由于产品已经发布上线，在重构新版的过程中还要一直维护着老版本，所以如何维护好两个版本的代码就成了一个问题。由于我们的团队一直以来使用Git时都忽视了其最大的优势 - 分支管理，所以正好趁此机会规范团队中Git的使用姿势。
三、关键字提示
master指的是本地主分支，也就是我们新建项目首次关联到Git上的本地主分支；
origin/master指的是远程主分支，也就是我们新建项目首次提交到Git上的远程主分支；
HEAD指的是我们当前所开发的代码的版本指针，指向的是某个分支上的节点；
commit指的是在当前分支新建一个节点，保存当前的代码版本；
这四个是我下面要经常提到的关键字，其他的遇到了再另外解释；
四、引出问题
假设我们的产品版本A已经发布上线了，现在我们继续开发版本B，今天产品经理过来告诉你版本A有一个十万火急的Bug，这个时候我们肯定是想办法拿到版本A的代码去修复Bug，那么问题来了：
1、在拿
版本A的代码时，如何去保存我们写到一半的版本B的代码？
有的朋友肯定会把写到一半的代码commit到本地去解决这个问题，这是最简单的方式但是也是错误的方式，其仅仅是达到了目的，但是这样会在版本节点上留下很多垃圾数据，经常会误导团队的其他成员。
2、在修改完
版本A的Bug后，如何提交这次的修改呢？
在版本A的节点上直接进行commit的话，HEAD指针会游离出去，也就是我们经常遇见的问题HEAD detached at head或者HEAD detached from master，搞不好会丢失一部分代码，如果你已经遇到这个问题了，这里只提供方案就是找到HEAD现在所指向的未知分支，给其命名，然后合并到master分支上，具体操作自行搜索。
3、先不管用什么办法，假如我在修改完
版本A后真的将此次的修改记录成功提交了，如何恢复我写到一半的版本B的代码呢？
这里一定有修改完后选择不提交，直接手动合并到版本B的朋友，目的又达到了，但是这样会导致此次对版本A的修改以未知的方式记录到版本B上去了，时间长了恐怕自己都不知道当初是改了哪里了。
五、解决方案
带着以上三个问题，我们进行情景再现，用Demo来演示一个项目在Git上的正确管理步骤。
-
初始导入
现在我们拿到了版本A的代码，将其提交到远程Git仓库上大家应该是没有问题的，从Android Studio的版本节点树可以看到，可以看到我们有了本地主分支master和远程主分支origin/master，HEAD指向的是本地的master分支。
-
创建开发分支
现在版本A已经发布，我们要进行版本B的开发了，这里最关键的是我们不可以在master主支上直接进行开发，master主支应当作为生产环境上的正式版本的发布分支，该分支的每个版本最好是有效的、干净的，原则上严禁对发布版本直接进行修改。所以我们需要一个开发分支，称为developer分支，这个分支用来专门开发新版本。
现在我们从版本A创建出一个developer分支，在工作空间根目录cmd下执行：git branch developer master即从
master创建developer的意思，版本树如下：
可以看到我们现在有了本地的developer分支，我们还要把该分支上传到远程仓库，执行
git push origin developer:developer
执行结果如下，意思是将本地的developer分支上传到远程origin/developer，如果远程不存在'origin/developer'分支，则新建之
为了便于观察，我在developer分支上提交了一个节点，现在观察版本树
-
保存正在写的代码
现在我们正在developer分支上改动代码，但是master分支出现了一个紧急的bug，我们应该执行git stash，作用是暂存我们在developer上做的没有提交的修改，然后我们执行
git branch bugbranch master
从master分支检出一个新的bug分支bugbranch，而不是直接切换到master分支上进行修改。现在观察版本树，可以看到从master分支分离出了bugbranch分支，现在HEAD指向的就是该分支。
-
修复bug
现在我们在bugbranch分支上修复了bug，并且测试通过了，那么接下来我们需要把修复后的代码commit一次，做一个节点保存记录一下，现在观察版本树
-
合并bug分支
在bugbranch分支上我们已经修复了bug，那么我们需要将bugbranch分支上修复后的代码合并到master分支上去，做一个节点并且发布新版本，先切换到master分支git checkout master，然后执行
git merge bugbranch
将bugbranch分支合并到master分支上，现在观察版本树
可以看到现在master和bugbranch分支上的代码已经合并成功一致，接下来还要将最新的代码push到远程分支上去，执行git push origin master:master，观察下边的版本树可以看到，现在本地和远程分支上的代码都已经更新完成，我们可以发布新版本了
-
合并修复的bug到开发分支
到了这里bugbranch分支的任务就完成了，我个人认为已经没有保留的必要了，因为本次修改的过程已经记录到了master的节点上，如果以后出了问题，再从当前节点重新检出一个分支就好，执行
git branch -d bugbranch
删除bugbranch分支，现在bug已经修复并且发布，我们需要回到正常的开发分支上去继续开发新的功能，执行git checkout developer先切换到developer分支，然后执行
git stash pop
取出我们当时在developer分支上stash的未提交的代码，至于我们在master分支上修复的bug怎么更新到developer分支上，分两种情况处理：
1、如果该bug影响到新模块的开发，那就手动更新修复部分的代码，到时候新模块开发完成之后我们将
developer分支合并回master的时候就会产生冲突，解决掉就好；
2、如果该bug对新模块的开发没影响，那就不用做处理，到时候将
developer分支合并回master之后修复后的代码自然就更新了。
-
合并开发分支到master
现在我们developer分支上的新功能写完并且测试通过了，我们需要先将developer分支上的代码都提交到远程'developer'分支上，我们发布新版本的时候需要先将developer分支的代码合并到master分支上去，执行git checkout master切换到master分支，执行get merge developer来进行合并，这个时候可能会产生冲突，对照解决即可。
下面是developer分支向master合并的时候产生了冲突，解决掉合并后的版本树
接下来我们需要先将本地的
master分支提交更新到远程，可以发现虽然developer分支虽然成功合并到master上了，但是因为产生了冲突，developer分支比master分支落后两个节点（分别是1.解决merge冲突的节点 2.当初修改的bug节点），也就意味着代码有了差别，如下图所示：
如果出现这种情况，需要再次执行get merge developer，再合并一次，这次冲突已经被解决了，直接合并成功，接下来我们直接将本地的developer分支代码提交到远程origin/developer分支即可，最终的代码树如下：
六、后言
在快速迭代开发中，经常会有需要紧急处理生产环境版本bug的时候，按照这样的分支管理操作，可以做到快速的拿到每一个发布版的代码；在开发新模块、修复旧bug、恢复旧版本的时候不互相污染代码；干净、清楚的记录每次更新、修复、迭代的内容。
从业以来的两个团队都没有一个成熟的git分支管理使用方案，这些处理方式是我在实际工作中摸索、总结出来的，是否跟真正正确的使用方式一致不太清楚，但是确实是解决掉我项目重构中实际遇到的问题了，感觉比较适合中小型团队使用，因为大团队我也没去过，有什么错误欢迎指出讨论，哈哈。
网友评论