【Git之窗】（四）Git分支管理

       Git的分支管理，可以说是区别于其他“VCS”最重要的一个标志，也是Git这个工具的“必杀器”！

      

 一、Git和其他VCS分支的原理比较

     1、其他“VCS”分支的原理：

     备份所有项目文件到特定的目录（新的分支目录）当中，但是备份的时间会随着文件数量、项目大小等因素的不同而不同，可能新建或者切换分支的时间就要几分钟。

      2、Git分支的原理：

      由于Git中的分支实际上仅仅是一个包含所指对象校验和（40个字符长度SHA-1子串）的文件，所以创建和销毁一个分支就会变得非常廉价，新建一个分支就是向一个文件中写入41个字节（外加一个换行符）那么简单，当然速度就是“瞬间”级别的了。

      小结：对比Git和SVN在市面上的书籍，“分支管理”这个章节，在SVN里，是放到高级部分讲的，在Git里，第二章就开始讲了。

二、一个实例，玩转Git分支

       备注：本节中插图来自《Pro Git》这本书，想要深入了解可以参考《Pro Git》

       先看一张图片，如图：

                            

       1、有几个概念：

      （1）绿色的框：三个绿框，分别还写着“98ca9”、“34ac2”、“f30ab”，代表进行了三次commit操作。还记得上一篇博客中我写过，执行commit命令之后会以一个HashCode作为每次commit的标识，其中的箭头指向的就是上一次的commit，可见三次commit操作，先是“98ca9”，再是“34ac2”，最后是“f30ab”。

      （2）灰色的框：“master”和“testing”分别代表了两个分支，“master”是系统默认的主分支，“testing”则是用户自定义出来的一个测试分支。

      （3）黑色的框：“HEAD”可以理解成一个指针，它指向当前的工作中的分支；

      2、 实战：

     （1）当执行“git branch testing”切换到“testing”分支之后，HEAD就会指向"testing"上面，如图：

                                  

         有意思的是，当创建一个新的分支，比如“dev”分支，通过"git branch dev"之后，此时会多出一个灰色的框，但是HEAD指针并不会指到“dev”上面去。

     （2）此时，当前工作的分支为"testing"分支，紧接着在这个分支上执行一次commit操作，如图：

                           

         此时，"master"和“testing”已经指向了不同的版本，“master”仍然在“f30ab”上面，“testing”已经到了“c2b9e”上， 而且HEAD指针也指向了"testing"分支。

     （3）执行"git checkout master"命令将代码切换到“master”分支上面，此时HEAD又会跳到“master”上面，同时工作代码回到了"f30ab"这个版本的快照上面，如图：

                                 

        （4）这个时候，我在"f30ab"这一版本的快照上面，进行了修改操作，之后执行“git add”以及“git commit”操作，这个时候，工作快照开始产生了分叉，如图：

                         

          如上图，此时又产生了一个新的快照“87ab2”，同时master分支在这版代码上面，HEAD指针指向着它。经过了这4个步骤的小实例，对于分支理解，应该就差不多了。

三、分支管理

     Git的创始人Linus对Git分支层次的划分特别巧妙，让人感觉他做的不是一个VCS，而是一个公司的结构管理方案，通俗的讲，Git的分支可以划分为如下三个层次：

      -------------------

       1）长期分支

       2）特性分支

       3）远程分支         

      -------------------

     1、长期分支 

      如图所示：

          

          可见，所谓“长期分支”就是我在公司里所使用的那种固定的分支结构，这种结构是不会变的，所以称之为“长期”，可以看做是运用Git合作开发过程中的一个框架，“master” 分支作为和远程remote origin分支的接口，负责“pull”、“push”操作，以及代码版本的标准化；“develop” 分支作为自己开发的分支，自己所写的代码就在这里产生，测试，没有问题了，"rebase"或者“merge”到“master”分支上面，如图所示，topic分支最终合并到develop上，develop最终合并到master上面。

     这种结构，适合用在大型的项目中，对于代码稳定性、层次的筛选都很棒，只有测试稳定了的代码，才能够进入一个更高的级别。

      2、特性分支

     如图所示，这是一个拥有多个特性分支的提交历史记录：

                  

         可见，其中拥有“master”分支，“dumbidea”分支，“iss91”分支，“iss91v2”分支，创建“iss91”以及“iss91v2”分支的目的在于有一个棘手的问题，而这个问题有两套不同的解决方案，此时就分别开启两个分支来解决这个问题，经过最终测试评估，发现“iss91v2”更加适合，就抛弃了“iss91”分支，并将“dumbidea”和“iss91”合并到master上，如图：

                        

         3、远程分支

     无论是gitLab还是gitHub，远程分支就像是书签，提醒着我们上次连接远程仓库时上面各个分支的位置。

     这就是对Git分支管理的基本介绍。

     That's all.