Git 学习（六）分支管理

Git 学习（六）分支管理

 

　　几乎每一种版本控制系统都支持分支。使用分支意味着你可以从开发主线上分离开来，然后不影响主线的同时继续工作。在很多版本控制系统中，这是个昂贵的过程，常常需要创建一个源代码目录的完整副本，对大型项目来说会花费很长时间。

　　作为优越的版本控制系统，Git 对分支的管理是极其轻便易用的。本文具体说明Git是如何进行分支管理的，如分支的创建、查看、切换、删除等，以及分支的合并及冲突解决。分支对于多人协作是及其重要，内容较多，慢慢来~

有人把 Git 的分支模型称为“必杀技特性”，而正是因为它，将 Git 从版本控制系统家族里区分出来。Git 有何特别之处呢？Git 的分支可谓是难以置信的轻量级，它的新建操作几乎可以在瞬间完成，并且在不同分支间切换起来也差不多一样快。和许多其他版本控制系统不同，Git 鼓励在工作流程中频繁使用分支与合并，哪怕一天之内进行许多次都没有关系。理解分支的概念并熟练运用后，你才会意识到为什么 Git 是一个如此强大而独特的工具，并从此真正改变你的开发方式。

 

何谓分支

分支的理念就是分身，就像孙悟空拔出猴毛变出很多跟自己一模一样的猴子，然后每个猴子（程序猿）做自己的事情互不干涉，等到所有猴子做完之后，猴子集合来合并劳动成果，然后悟空就把那些猴子猴孙门统统收回了。

其他版本控制系统如SVN等都有分支管理，但是用过之后你会发现，这些版本控制系统创建和切换分支比蜗牛还慢，简直让人无法忍受，结果分支功能成了摆设，大家都不去用。但Git的分支是与众不同的，无论创建、切换和删除分支，Git在1秒钟之内就能完成！无论你的版本库是1个文件还是1万个文件。

为了理解 Git 分支的实现方式，我们需要回顾一下 Git 是如何储存数据的。或许你还记得第一章的内容，Git 保存的不是文件差异或者变化量，而只是一系列文件快照。这就使得 Git分支创建及切换等操作就如拔毛一样迅速。

 

创建分支、查看及切换

在本地仓库操作一章中，可知道，每次提交，Git都把它们串成一条时间线，这条时间线就是一个分支。只是目前，只有一条时间线，在Git里，这个分支叫主分支，即master分支。HEAD严格来说不是指向提交，而是指向master，master才是指向提交的，所以，HEAD指向的就是当前分支。每次提交，master分支都会向前移动一步，这样，随着你不断提交，master分支的线也越来越长。

 

 当我们创建新的分支，例如dev时，Git新建了一个指针叫dev，指向master相同的提交，再把HEAD指向dev （切换分支），就表示当前分支在dev上：

从现在开始，对工作区的修改和提交就是针对dev分支了，比如新提交一次后，dev指针往前移动一步，而master指针不变：

 

有了上述的理解，我们开始具体的操作实战，首先来了解一下几个Git 命令：

git branch　　　　　　　　　　　　      查看分支 

git branch <branch name>　　 　       创建分支

git checkout <branch name>　　        切换分支

git checkout  -b  <branch name>　　 创建分支并切换

 

 可使用之前章节本地仓库操作使用过的git库，查看当前git库分支，由于没有其他分支操作，仅有一master分支； git branch dev 创建一dev分支，并查看，可见此时有两个分支，但指向仍是master

　  　; 　　

 

切换分支至 dev， git checkout dev  ，可见此时指向是 dev 分支了； 创建及切换可并为一步，如我们创建并指向 一 bug 分支  git checkout -b bug ，目前我们有三条分支，且指向是新建的bug分支了

　  　 ;    

在操作过程中，是不是很迅速，即使git库很庞大也是如此，正如前文所言，git 分支管理是如此的轻便易用，当你切换分支后，就不用担心当前的操作会影响他人及主线了。

 

合并分支

Git怎么合并呢？最简单的方法，就是直接把master指向dev的当前提交，就完成了合并：

 

合并分支命令如下：

git  merge <branch name>　　　　　 合并某分支至当前分支

 

暂不考虑冲突的情况，来实际操作下 merge 及删除分支。

在文件夹下 init git库，添加 a.txt，add并commit；创建 dev 分支并切换至该分支，在dev分支上新建文件，如 b.txt， add 并 commit；切换至 master 分支并 merge dev分支

git merge命令用于合并指定分支到当前分支。合并后，再查看文件夹，就可以看到，和dev分支的最新提交是完全一样的。

注意到上面的Fast-forward信息，Git告诉我们，这次合并是“快进模式”，也就是直接把master指向dev的当前提交，所以合并速度非常快。

当然，也不是每次合并都能Fast-forward，其他方式的合并会后续介绍。

同样的，操作同一文件内容的修改，且未产生冲突的情况。如 dev 分支上，修改 a.txt， 如仅在该文件追加记录内容，切换master分支并合并， 如下：

如果dev分支变动，master分支也有对应变动，则可能引发冲突；此时，如果仍使用上述方式merge，则会报错，具体的解决冲突方式将于后续介绍。

 

删除分支

 正如上文所言，Git 是鼓励使用多分支的，就会有很多分支的存在，然而多余分支管理上必然会比较杂乱；故，需删除无用的分支，删除分支命令如下：

git branch -d <branch name>　　 　  删除分支

 

同样的，操作删除dev分支，如下：

 

若dev分支未merge至master，则会报警如下：

   可见 "-D" 可以无视merge，删除分支。

 

冲突解决

之前的merge即合并分支章节，有提及冲突；现在，来具体说明下冲突的产生及 Git是如何解决冲突的。

首先，了解下冲突的产生，如在时间节点a，从master上分支出feature1分支，feature1分支上对文件f做了更新，此时准备merge至master；如master分支在 a时间节点后已对文件f做了更新并提交；此时，就可能产生冲突。

这种情况下，Git无法执行“快速合并”，只能试图把各自的修改合并起来，但这种合并就可能会有冲突。

简单模拟下该情况： master分支 1.txt 文件内容为 "aaa"； 此时，分支出feature1，更改 1.txt 内容为"feature" 并commit；切换至master分支，更改 1.txt 内容为 "bbb"；

此时，若是执行快速merge，即master下   git merge feature1 

会报错如上，且告知，1.txt文件存在冲突，必须解决冲突后再提交。git status也可以告诉我们冲突的文件。手动打开 1.txt，可见如下：

Git用<<<<<<<，=======，>>>>>>>标记出不同分支的内容，我们修改如下后保存并提交：

  

 

此时，master及feature1就变成了如下图（绿线表示已合并）

git log 可看出带上了feature1分支的提交，以及最后一次的手动解决冲突

  

 

远程分支

远程分支的操作其实和本地大同小异，只是需要指向远程。

当你从远程仓库克隆时，实际上Git自动把本地的master分支和远程的master分支对应起来了，并且，远程仓库的默认名称是origin。

要查看远程库的信息，可用git remote， git remote -v显示更详细的信息：

　　git remote　　 　  显示远程库信息



上面显示了可以抓取和推送的origin的地址。如果没有推送权限，就看不到push的地址。

至于远程推送，之前可知用 git push origin master ， 如若推送远程其他的分支，如 git push origin dev， 更改名称即可。

远程获取同样如此，如：  git pull origin dev。

远程分支push，可能会产生冲突，此时如何解决？其实同分支冲突解决雷同，只须多加一步，即首先 pull 最新的远程分支，再merge，若仍有冲突，则须手动解决冲突后再次 push即可。

 

分支策略

其实之前的的章节已提及了一些关键分支的策略，即 master 分支、dev分支 及 bug、feature分支等。

 

通常应用于团队的分支管理策略如下：

首先，master分支应该是非常稳定的，基本上仅用来发布新版本；

其次，代码的coding都在dev分支上；dev分支是不稳定的，到某个时候，比如2.0版本发布时，再把dev分支合并到master上，在master分支发布2.0版本；

然后，自然每个人都有自己的分支，时不时地往dev分支上合并就可以了。

所以，团队合作的分支看起来就像这样：