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分支上合并就能够了。

因此，团队合做的分支看起来就像这样：