Git分支

前面的话

　　几乎每一种版本控制系统都以某种形式支持分支。使用分支意味着能够从开发主线上分离开来，而后在不影响主线的同时继续工做。在不少版本控制系统中，这是个昂贵的过程，经常须要建立一个源代码目录的完整副本，对大型项目来讲会花费很长时间

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

 

定义

　　为了理解Git分支的实现方式，咱们须要回顾一下Git是如何储存数据的。Git保存的不是文件差别或者变化量，而只是一系列文件快照

　　在Git中提交时，会保存一个提交(commit)对象，该对象包含一个指向暂存内容快照的指针，包含本次提交的做者等相关附属信息，包含零个或多个指向该提交对象的父对象指针：首次提交是没有直接祖先的，普通提交有一个祖先，由两个或多个分支合并产生的提交则有多个祖先

　　为直观起见，咱们假设工做目录中有三个文件，准备将它们暂存后提交。暂存操做会对每个文件计算校验和，而后把当前版本文件快照保存到Git仓库(Git使用blob类型的对象存储这些快照)，并将校验和加入暂存区域

$ git add README test.rb LICENSE
$ git commit -m 'initial commit of my project'

　　当使用git commit新建一个提交对象前，Git会先计算每个子目录(本例中就是项目根目录)的校验和，而后在Git仓库中将这些目录保存为树(tree)对象。以后Git建立的提交对象，除了包含相关提交信息之外，还包含着指向这个树对象(项目根目录)的指针，如此它就能够在未来须要的时候，重现这次快照的内容了

　　如今，Git仓库中有五个对象：三个表示文件快照内容的blob对象；一个记录着目录树内容及其中各个文件对应blob对象索引的tree对象；以及一个包含指向tree对象(根目录)的索引和其余提交信息元数据的commit对象。概念上来讲，仓库中的各个对象保存的数据和相互关系看起来以下图所示

　　作些修改后再次提交，那么此次的提交对象会包含一个指向上次提交对象的指针(即下图中的parent对象)。两次提交后，仓库历史会变成下图的样子

　　如今来谈分支。Git中的分支，其实本质上仅仅是个指向commit对象的可变指针。Git会使用master做为分支的默认名字。在若干次提交后，其实已经有了一个指向最后一次提交对象的master分支，它在每次提交的时候都会自动向前移动

　　那么，Git又是如何建立一个新的分支的呢？答案很简单，建立一个新的分支指针。好比新建一个testing分支，可使用git branch命令：

$ git branch testing

　　这会在当前commit对象上新建一个分支指针

　　那么，Git是如何知道你当前在哪一个分支上工做的呢？其实答案也很简单，它保存着一个名为HEAD的特别指针。请注意它和你熟知的许多其余版本控制系统(好比Subversion或CVS)里的HEAD概念大不相同。在Git中，它是一个指向你正在工做中的本地分支的指针(能够将HEAD想象为当前分支的别名)。运行git branch命令，仅仅是创建了一个新的分支，但不会自动切换到这个分支中去，因此在这个例子中，咱们依然还在master分支里工做

　　要切换到其余分支，能够执行git checkout命令。咱们如今转换到新建的testing分支

$ git checkout testing

　　这样HEAD就指向了testing分支

　　这样的实现方式会给咱们带来什么好处呢？好吧，如今不妨再提交一次：

$ git commit -a -m 'made a change'

　　很是有趣，如今testing分支向前移动了一格，而master分支仍然指向原先git checkout时所在的commit对象。如今咱们回到master分支看看

$ git checkout master

　　这条命令作了两件事。它把HEAD指针移回到master分支，并把工做目录中的文件换成了master分支所指向的快照内容。也就是说，如今开始所作的改动，将始于本项目中一个较老的版本。它的主要做用是将testing分支里做出的修改暂时取消，这样你就能够向另外一个方向进行开发

$ git commit -a -m 'made other changes'

　　如今咱们的项目提交历史产生了分叉，由于刚才咱们建立了一个分支，转换到其中进行了一些工做，而后又回到原来的主分支进行了另一些工做。这些改变分别孤立在不一样的分支里：咱们能够在不一样分支里反复切换，并在时机成熟时把它们合并到一块儿。而全部这些工做，仅仅须要branch和checkout这两条命令就能够完成

　　因为Git中的分支实际上仅是一个包含所指对象校验和(40个字符长度SHA-1字串)的文件，因此建立和销毁一个分支就变得很是廉价。说白了，新建一个分支就是向一个文件写入41个字节(外加一个换行符)那么简单，固然也就很快了

　　这和大多数版本控制系统造成了鲜明对比，它们管理分支大多采起备份全部项目文件到特定目录的方式，因此根据项目文件数量和大小不一样，可能花费的时间也会有至关大的差异，快则几秒，慢则数分钟。而Git的实现与项目复杂度无关，它永远能够在几毫秒的时间内完成分支的建立和切换。同时，由于每次提交时都记录了祖先信息(即parent对象)，未来要合并分支时，寻找恰当的合并基础(即共同祖先)的工做其实已经天然而然地摆在那里了，因此实现起来很是容易。Git鼓励开发者频繁使用分支，正是由于有着这些特性做保障

　　接下来看看，咱们为何应该频繁使用分支

 

新建与合并

　　如今让咱们来看一个简单的分支与合并的例子，实际工做中大致也会用到这样的工做流程：

　　一、开发某个网站

　　二、为实现某个新的需求，建立一个分支

　　三、在这个分支上开展工做

　　假设此时，忽然接到一个电话说有个很严重的问题须要紧急修补，那么能够按照下面的方式处理：

　　一、返回到原先已经发布到生产服务器上的分支

　　二、为此次紧急修补创建一个新分支，并在其中修复问题

　　三、经过测试后，回到生产服务器所在的分支，将修补分支合并进来，而后再推送到生产服务器上。

　　四、切换到以前实现新需求的分支，继续工做

【新建与切换】

　　假设你正在项目中愉快地工做，而且已经提交了几回更新

　　如今，决定要修补问题追踪系统上的#53问题。顺带说明下，Git并不一样任何特定的问题追踪系统打交道。这里为了说明要解决的问题，才把新建的分支取名为iss53。要新建并切换到该分支，运行git checkout并加上-b参数

$ git checkout -b iss53
Switched to a new branch 'iss53'

$ git branch iss53
$ git checkout iss53

　　接着开始尝试修复问题，在提交了若干次更新后，iss53分支的指针也会随着向前推动，由于它就是当前分支(换句话说，当前的HEAD指针正指向iss53)

$ git commit -a -m 'added a new footer [issue 53]'

　　如今你就接到了那个网站问题的紧急电话，须要立刻修补。有了Git，咱们就不须要同时发布这个补丁和iss53里做出的修改，也不须要在建立和发布该补丁到服务器以前花费大力气来复原这些修改。惟一须要的仅仅是切换回master分支

　　不过在此以前，留心你的暂存区或者工做目录里，那些尚未提交的修改，它会和你即将检出的分支产生冲突从而阻止Git为你切换分支。切换分支的时候最好保持一个清洁的工做区域。稍后会介绍几个绕过这种问题的办法(分别叫作stashing和commitamending)。目前已经提交了全部的修改，因此接下来能够正常转换到master分支：

$ git checkout master
Switched to branch 'master'

　　此时工做目录中的内容和你在解决问题#53以前如出一辙，你能够集中精力进行紧急修补。这一点值得牢记：Git会把工做目录的内容恢复为检出某分支时它所指向的那个提交对象的快照。它会自动添加、删除和修改文件以确保目录的内容和你当时提交时彻底同样

　　接下来，你得进行紧急修补。咱们建立一个紧急修补分支hotfix来开展工做，直到搞定

$ git checkout -b hotfix
Switched to a new branch 'hotfix'

$ git commit -a -m 'fixed the broken email address'
[hotfix 3a0874c] fixed the broken email address
 1 files changed, 1 deletion(-)

　　有必要做些测试，确保修补是成功的，而后回到master分支并把它合并进来，而后发布到生产服务器。用git merge命令来进行合并

$ git checkout master
$ git merge hotfix
Updating f42c576..3a0874c
Fast-forward
 README | 1 -
 1 file changed, 1 deletion(-)

　　请注意，合并时出现了“Fast forward”的提示。因为当前master分支所在的提交对象是要并入的hotfix分支的直接上游，Git只需把master分支指针直接右移。换句话说，若是顺着一个分支走下去能够到达另外一个分支的话，那么Git在合并二者时，只会简单地把指针右移，由于这种单线的历史分支不存在任何须要解决的分歧，因此这种合并过程能够称为快进(Fast forward)

　　如今最新的修改已经在当前master分支所指向的提交对象中了，能够部署到生产服务器上去了

　　在那个超级重要的修补发布之后，你想要回到被打扰以前的工做。因为当前hotfix分支和master都指向相同的提交对象，因此hotfix已经完成了历史使命，能够删掉了。使用git branch 的-d选项执行删除操做

$ git branch -d hotfix
Deleted branch hotfix (was 3a0874c).

　　如今回到以前未完成的#53问题修复分支上继续工做

$ git checkout iss53
Switched to branch 'iss53'

$ git commit -a -m 'finished the new footer [issue 53]'
[iss53 ad82d7a] finished the new footer [issue 53]
 1 file changed, 1 insertion(+)

　　值得注意的是以前hotfix分支的修改内容还没有包含到iss53中来。若是须要归入这次修补，能够用git merge master把master分支合并到iss53；或者等iss53完成以后，再将iss53分支中的更新并入master

【分支的合并】

　　在问题#53相关的工做完成以后，能够合并回master分支。实际操做同前面合并hotfix分支差很少，只需回到master分支，运行git merge命令指定要合并进来的分支：

$ git checkout master
$ git merge iss53
Auto-merging README
Merge made by the 'recursive' strategy.
 README | 1 +
 1 file changed, 1 insertion(+)

　　请注意，此次合并操做的底层实现，并不一样于以前hotfix的并入方式。由于此次你的开发历史是从更早的地方开始分叉的。因为当前master分支所指向的提交对象(C4)并非iss53分支的直接祖先，Git不得不进行一些额外处理。就此例而言，Git会用两个分支的末端(C4和C5)以及它们的共同祖先(C2)进行一次简单的三方合并计算。下图用红框标出了Git用于合并的三个提交对象

　　此次，Git没有简单地把分支指针右移，而是对三方合并后的结果从新作一个新的快照，并自动建立一个指向它的提交对象(C6)。这个提交对象比较特殊，它有两个祖先(C4和C5)

　　值得一提的是Git能够本身裁决哪一个共同祖先才是最佳合并基础；这和CVS或Subversion(1.5之后的版本)不一样，它们须要开发者手工指定合并基础。因此此特性让Git的合并操做比其余系统都要简单很多

　　既然以前的工做成果已经合并到master了，那么iss53也就没用了。你能够就此删除它，并在问题追踪系统里关闭该问题

$ git branch -d iss53

【遇到冲突时的分支合并】

　　有时候合并操做并不会如此顺利。若是在不一样的分支中都修改了同一个文件的同一部分，Git就没法干净地把二者合到一块儿(逻辑上说，这种问题只能由人来裁决)。若是你在解决问题#53的过程当中修改了hotfix中修改的部分，将获得相似下面的结果

$ git merge iss53
Auto-merging index.html
CONFLICT (content): Merge conflict in index.html
Automatic merge failed; fix conflicts and then commit the result.

　　Git做了合并，但没有提交，它会停下来等你解决冲突。要看看哪些文件在合并时发生冲突，能够用git status查阅：

$ git status
On branch master
You have unmerged paths.
  (fix conflicts and run "git commit")

Unmerged paths:
  (use "git add <file>..." to mark resolution)

        both modified:      index.html

no changes added to commit (use "git add" and/or "git commit -a")

　　任何包含未解决冲突的文件都会以未合并(unmerged)的状态列出。Git会在有冲突的文件里加入标准的冲突解决标记，能够经过它们来手工定位并解决这些冲突。能够看到此文件包含相似下面这样的部分：

<<<<<<< HEAD
<div id="footer">contact : email.support@github.com</div>
=======
<div id="footer">
  please contact us at support@github.com
</div>
>>>>>>> iss53

　　能够看到=======隔开的上半部分，是HEAD(即master分支，在运行merge命令时所切换到的分支)中的内容，下半部分是在iss53分支中的内容。解决冲突的办法无非是两者选其一或者由你亲自整合到一块儿。好比你能够经过把这段内容替换为下面这样来解决：

<div id="footer">
please contact us at email.support@github.com
</div>

　　这个解决方案各采纳了两个分支中的一部份内容，并且我还删除了<<<<<<<，=======和>>>>>>>这些行。在解决了全部文件里的全部冲突后，运行git add将把它们标记为已解决状态(实际上就是将一次快照保存到暂存区域)。由于一旦暂存，就表示冲突已经解决。若是你想用一个有图形界面的工具来解决这些问题，不妨运行git mergetool，它会调用一个可视化的合并工具并引导你解决全部冲突：

$ git mergetool

This message is displayed because 'merge.tool' is not configured.
See 'git mergetool --tool-help' or 'git help config' for more details.
'git mergetool' will now attempt to use one of the following tools:
opendiff kdiff3 tkdiff xxdiff meld tortoisemerge gvimdiff diffuse diffmerge ecmerge p4merge araxis bc3 codecompare vimdiff emerge
Merging:
index.html

Normal merge conflict for 'index.html':
  {local}: modified file
  {remote}: modified file
Hit return to start merge resolution tool (opendiff):

　　若是不想用默认的合并工具，你能够在上方"merge tool candidates"里找到可用的合并工具列表，输入你想用的工具名

　　退出合并工具之后，Git会询问你合并是否成功。若是回答是，它会为你把相关文件暂存起来，以代表状态为已解决

　　再运行一次git status来确认全部冲突都已解决：

$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        modified:   index.html

　　若是以为满意了，而且确认全部冲突都已解决，也就是进入了暂存区，就能够用git commit来完成此次合并提交。提交的记录差很少是这样：

Merge branch 'iss53'

Conflicts:
  index.html
#
# It looks like you may be committing a merge.
# If this is not correct, please remove the file
#       .git/MERGE_HEAD
# and try again.
#

　　若是想给未来看此次合并的人一些方便，能够修改该信息，提供更多合并细节。好比你都做了哪些改动，以及这么作的缘由。有时候裁决冲突的理由并不直接或明显，有必要略加注解

 

分支管理

　　git branch命令不只仅能建立和删除分支，若是不加任何参数，它会给出当前全部分支的清单

$ git branch
  iss53
* master
  testing

　　注意看master分支前的*字符：它表示当前所在的分支。也就是说，若是如今提交更新，master分支将随着开发进度前移。若要查看各个分支最后一个提交对象的信息，运行git branch -v：

$ git branch -v
  iss53   93b412c fix javascript issue
* master  7a98805 Merge branch 'iss53'
  testing 782fd34 add scott to the author list in the readmes

　　要从该清单中筛选出你已经(或还没有)与当前分支合并的分支，能够用--merged和--no-merged选项(Git1.5.6以上版本)。好比用git branch --merged查看哪些分支已被并入当前分支，也就是说哪些分支是当前分支的直接上游

$ git branch --merged
  iss53
* master

　　以前咱们已经合并了iss53，因此在这里会看到它。通常来讲，列表中没有*的分支一般均可以用git branch -d来删掉。缘由很简单，既然已经把它们所包含的工做整合到了其余分支，删掉也不会损失什么

　　另外能够用git branch --no-merged查看还没有合并的分支

$ git branch --no-merged
  testing

　　它会显示还未合并进来的分支。因为这些分支中还包含着还没有合并进来的工做成果，因此简单地用 git branch -d删除该分支会提示错误，由于那样作会丢失数据：

$ git branch -d testing
error: The branch 'testing' is not fully merged.
If you are sure you want to delete it, run 'git branch -D testing'.

　　不过，若是你确实想要删除该分支上的改动，能够用大写的删除选项-D强制执行，就像上面提示信息中给出的那样

 

工做流程

　　因为分支管理的便捷，衍生出了这类典型的工做模式，能够根据项目的实际状况进行选择

【长期分支】

　　因为Git使用简单的三方合并，因此就算在较长一段时间内，反复屡次把某个分支合并到另外一分支，也不是什么难事。也就是说，你能够同时拥有多个开放的分支，每一个分支用于完成特定的任务，随着开发的推动，你能够随时把某个特性分支的成果并到其余分支中

　　许多使用Git的开发者都喜欢用这种方式来开展工做，好比仅在master分支中保留彻底稳定的代码，即已经发布或即将发布的代码。与此同时，他们还有一个名为develop或next的平行分支，专门用于后续的开发，或仅用于稳定性测试—固然并非说必定要绝对稳定，不过一旦进入某种稳定状态，即可以把它合并到master里。这样，在确保这些已完成的特性分支(短时间分支，好比以前的iss53分支)可以经过全部测试，而且不会引入更多错误以后，就能够并到主干分支中，等待下一次的发布。

　　本质上咱们刚才谈论的，是随着提交对象不断右移的指针。稳定分支的指针老是在提交历史中落后一大截，而前沿分支老是比较靠前

　　或者把它们想象成工做流水线，或许更好理解一些，通过测试的提交对象集合被遴选到更稳定的流水线

　　你能够用这招维护不一样层次的稳定性。某些大项目还会有个proposed(建议)或pu(proposed updates，建议更新)分支，它包含着那些可能尚未成熟到进入next或master的内容。这么作的目的是拥有不一样层次的稳定性：当这些分支进入到更稳定的水平时，再把它们合并到更高层分支中去。再次说明下，使用多个长期分支的作法并不是必需，不过通常来讲，对于特大型项目或特复杂的项目，这么作确实更容易管理

【特性分支】

　　在任何规模的项目中均可以使用特性(Topic)分支。一个特性分支是指一个短时间的，用来实现单一特性或与其相关工做的分支。可能你在之前的版本控制系统里从未作过相似这样的事情，由于一般建立与合并分支消耗太大。然而在Git中，一天以内创建、使用、合并再删除多个分支是常见的事

　　咱们在上节的例子里已经见过这种用法了。咱们建立了iss53和hotfix这两个特性分支，在提交了若干更新后，把它们合并到主干分支，而后删除。该技术容许你迅速且彻底的进行语境切换——由于你的工做分散在不一样的流水线里，每一个分支里的改变都和它的目标特性相关，浏览代码之类的事情于是变得更简单了。你能够把做出的改变保持在特性分支中几分钟，几天甚至几个月，等它们成熟之后再合并，而不用在意它们创建的顺序或者进度

　　如今咱们来看一个实际的例子，以下图所示，由下往上，起先咱们在master工做到C1，而后开始一个新分支iss91尝试修复91号缺陷，提交到C6的时候，又冒出一个解决该问题的新办法，因而从以前C4的地方又分出一个分支iss91v2，干到C8的时候，又回到主干master中提交了C9和C10，再回到iss91v2继续工做，提交C11，接着，又冒出个不太肯定的想法，从master的最新提交C10处开了个新的分支dumbidea作些试验

　　如今，假定两件事情：咱们最终决定使用第二个解决方案，即iss91v2中的办法；另外，咱们把dumbidea分支拿给同事们看了之后，发现它居然是个天才之做。因此接下来，咱们准备抛弃原来的iss91分支(实际上会丢弃C5和C6)，直接在主干中并入另外两个分支。最终的提交历史将变成以下图所示

　　请务必牢记这些分支所有都是本地分支，这一点很重要。当你在使用分支及合并的时候，一切都是在你本身的Git仓库中进行的——彻底不涉及与服务器的交互

 

远程分支

　　远程分支(remote branch)是对远程仓库中的分支的索引。它们是一些没法移动的本地分支；只有在Git进行网络交互时才会更新。远程分支就像是书签，提醒着你上次链接远程仓库时上面各分支的位置

　　咱们用(远程仓库名)/(分支名)这样的形式表示远程分支。好比咱们想看看上次同origin仓库通信时master分支的样子，就应该查看origin/master分支。若是你和同伴一块儿修复某个问题，但他们先推送了一个iss53分支到远程仓库，虽然你可能也有一个本地的iss53分支，但指向服务器上最新更新的却应该是origin/iss53分支

　　可能有点乱，咱们不妨举例说明。假设大家团队有个地址为git.ourcompany.com的Git服务器。若是你从这里克隆，Git会自动为你将此远程仓库命名为origin，并下载其中全部的数据，创建一个指向它的master分支的指针，在本地命名为origin/master，但你没法在本地更改其数据。接着，Git创建一个属于你本身的本地master分支，始于origin上master分支相同的位置，你能够就此开始工做：

　　若是你在本地master分支作了些改动，与此同时，其余人向git.ourcompany.com推送了他们的更新，那么服务器上的master分支就会向前推动，而与此同时，你在本地的提交历史正朝向不一样方向发展。不过只要你不和服务器通信，你的origin/master指针仍然保持原位不会移动

　　能够运行git fetch origin来同步远程服务器上的数据到本地。该命令首先找到origin是哪一个服务器(本例为git.ourcompany.com)，从上面获取你还没有拥有的数据，更新你本地的数据库，而后把origin/master的指针移到它最新的位置上

　　为了演示拥有多个远程分支(在不一样的远程服务器上)的项目是如何工做的，咱们假设你还有另外一个仅供你的敏捷开发小组使用的内部服务器git.team1.ourcompany.com。能够用git remote add命令把它加为当前项目的远程分支之一。咱们把它命名为teamone，以便代替完整的Git URL以方便使用

　　如今你能够用git fetch teamone来获取小组服务器上你尚未的数据了。因为当前该服务器上的内容是你origin服务器上的子集，Git不会下载任何数据，而只是简单地建立一个名为teamone/master的远程分支，指向teamone服务器上master分支所在的提交对象31b8e

【推送本地分支】

　　要想和其余人分享某个本地分支，你须要把它推送到一个你拥有写权限的远程仓库。你建立的本地分支不会由于你的写入操做而被自动同步到你引入的远程服务器上，你须要明确地执行推送分支的操做。换句话说，对于无心分享的分支，你尽管保留为私人分支好了，而只推送那些协同工做要用到的特性分支

　　若是你有个叫serverfix的分支须要和他人一块儿开发，能够运行git push (远程仓库名) (分支名)：

$ git push origin serverfix
Counting objects: 20, done.
Compressing objects: 100% (14/14), done.
Writing objects: 100% (15/15), 1.74 KiB, done.
Total 15 (delta 5), reused 0 (delta 0)
To git@github.com:schacon/simplegit.git
 * [new branch]      serverfix -> serverfix

　　这里其实走了一点捷径。Git自动把serverfix分支名扩展为refs/heads/serverfix:refs/heads/serverfix，意为“取出我在本地的serverfix分支，推送到远程仓库的serverfix分支中去”

　　不过通常使用的时候均可以省略它。也能够运行git push origin serverfix:serverfix来实现相同的效果，它的意思是“上传我本地的serverfix分支到远程仓库中去，仍旧称它为serverfix分支”。经过此语法，你能够把本地分支推送到某个命名不一样的远程分支：若想把远程分支叫做awesomebranch，能够用git push origin serverfix:awesomebranch来推送数据

　　接下来，当你的协做者再次从服务器上获取数据时，他们将获得一个新的远程分支origin/serverfix，并指向服务器上serverfix所指向的版本：

$ git fetch origin
remote: Counting objects: 20, done.
remote: Compressing objects: 100% (14/14), done.
remote: Total 15 (delta 5), reused 0 (delta 0)
Unpacking objects: 100% (15/15), done.
From git@github.com:schacon/simplegit
 * [new branch]      serverfix    -> origin/serverfix

　　值得注意的是，在fetch操做下载好新的远程分支以后，你仍然没法在本地编辑该远程仓库中的分支。换句话说，在本例中，你不会有一个新的serverfix分支，有的只是一个你没法移动的origin/serverfix指针

　　若是要把该远程分支的内容合并到当前分支，能够运行git merge origin/serverfix。若是想要一份本身的serverfix来开发，能够在远程分支的基础上分化出一个新的分支来：

$ git checkout -b serverfix origin/serverfix
Branch serverfix set up to track remote branch serverfix from origin.
Switched to a new branch 'serverfix'

　　这会切换到新建的serverfix本地分支，其内容同远程分支origin/serverfix一致，这样就能够在里面继续开发了

【跟踪远程分支】

　　从远程分支checkout出来的本地分支，称为跟踪分支(tracking branch)。跟踪分支是一种和某个远程分支有直接联系的本地分支。在跟踪分支里输入git push，Git会自行推断应该向哪一个服务器的哪一个分支推送数据。一样，在这些分支里运行git pull会获取全部远程索引，并把它们的数据都合并到本地分支中来。

　　在克隆仓库时，Git一般会自动建立一个名为master的分支来跟踪origin/master。这正是git push和git pull一开始就能正常工做的缘由。固然，你能够为所欲为地设定为其它跟踪分支，好比origin上除了master以外的其它分支。刚才咱们已经看到了这样的一个例子：git checkout -b [分支名] [远程名]/[分支名]。若是你有1.6.2以上版本的 Git，还能够用--track选项简化：

$ git checkout --track origin/serverfix
Branch serverfix set up to track remote branch serverfix from origin.
Switched to a new branch 'serverfix'

　　要为本地分支设定不一样于远程分支的名字，只需在第一个版本的命令里换个名字：

$ git checkout -b sf origin/serverfix
Branch sf set up to track remote branch serverfix from origin.
Switched to a new branch 'sf'

　　如今你的本地分支sf会自动将推送和抓取数据的位置定位到origin/serverfix了

【删除远程分支】

　　若是再也不须要某个远程分支了，好比搞定了某个特性并把它合并进了远程的master分支(或任何其余存放稳定代码的分支)，能够用这个很是无厘头的语法来删除它：git push [远程名] :[分支名]。若是想在服务器上删除serverfix分支，运行下面的命令

$ git push origin :serverfix
To git@github.com:schacon/simplegit.git
 - [deleted]         serverfix

　　服务器上的分支没了。有种方便记忆这条命令的方法：记住咱们不久前见过的 git push [远程名] [本地分支]:[远程分支] 语法，若是省略 [本地分支]，那就等因而在说“在这里提取空白而后把它变成[远程分支]”

 

分支衍合

　　把一个分支中的修改整合到另外一个分支的办法有两种：merge 和 rebase(rebase的翻译为“衍合”或变基)

【基本的衍合操做】

　　在分支合并一节中，开发进程分叉到两个不一样分支，又各自提交了更新

　　最容易的整合分支的方法是merge命令，它会把两个分支最新的快照(C3和C4)以及两者最新的共同祖先(C2)进行三方合并，合并的结果是产生一个新的提交对象(C5)

　　其实，还有另一个选择：你能够把在C3里产生的变化补丁在C4的基础上从新打一遍。在Git里，这种操做叫作衍合(rebase)。有了rebase命令，就能够把在一个分支里提交的改变移到另外一个分支里重放一遍

$ git checkout experiment
$ git rebase master
First, rewinding head to replay your work on top of it...
Applying: added staged command

　　它的原理是回到两个分支最近的共同祖先，根据当前分支(也就是要进行衍合的分支experiment)后续的历次提交对象(这里只有一个C3)，生成一系列文件补丁，而后以基底分支(也就是主干分支master)最后一个提交对象(C4)为新的出发点，逐个应用以前准备好的补丁文件，最后会生成一个新的合并提交对象(C3')，从而改写experiment的提交历史，使它成为master分支的直接下游

　　如今回到master分支，进行一次快进合并

　　如今的C3'对应的快照，其实和普通的三方合并，即上个例子中的C5对应的快照内容如出一辙了。虽然最后整合获得的结果没有任何区别，但衍合能产生一个更为整洁的提交历史。若是视察一个衍合过的分支的历史记录，看起来会更清楚：仿佛全部修改都是在一根线上前后进行的，尽管实际上它们本来是同时并行发生的

　　通常咱们使用衍合的目的，是想要获得一个能在远程分支上干净应用的补丁——好比某些项目你不是维护者，但想帮点忙的话，最好用衍合：先在本身的一个分支里进行开发，当准备向主项目提交补丁的时候，根据最新的origin/master进行一次衍合操做而后再提交，这样维护者就不须要作任何整合工做(其实是把解决分支补丁同最新主干代码之间冲突的责任，化转为由提交补丁的人来解决)，只需根据你提供的仓库地址做一次快进合并，或者直接采纳你提交的补丁

　　[注意]合并结果中最后一次提交所指向的快照，不管是经过衍合，仍是三方合并，都会获得相同的快照内容，只不过提交历史不一样罢了。衍合是按照每行的修改次序重演一遍修改，而合并是把最终结果合在一块儿

【有趣的衍合】

　　衍合也能够放到其余分支进行，并不必定非得根据分化以前的分支。如下图为例，咱们为了给服务器端代码添加一些功能而建立了特性分支server，而后提交C3和C4。而后又从C3的地方再增长一个client分支来对客户端代码进行一些相应修改，因此提交了C8和C9。最后，又回到server分支提交了C10

　　假设在接下来的一次软件发布中，咱们决定先把客户端的修改并到主线中，而暂缓并入服务端软件的修改(由于还须要进一步测试)。这个时候，咱们就能够把基于client分支而非server分支的改变(即C8和C9)，跳过server直接放到master分支中重演一遍，但这须要用git rebase的--onto选项指定新的基底分支master

$ git rebase --onto master server client

　　这比如在说：“取出client分支，找出client分支和server分支的共同祖先以后的变化，而后把它们在master上重演一遍”

　　虽然client里的C8,C9在C3以后，但这仅代表时间上的前后，而非在C3修改的基础上进一步改动，由于server和client这两个分支对应的代码应该是两套文件，虽然这么说不是很严格，但应理解为在C3时间点以后，对另外的文件所作的C8，C9修改，放到主干重演

　　如今能够快进master分支了

$ git checkout master
$ git merge client

　　如今咱们决定把server分支的变化也包含进来。咱们能够直接把server分支衍合到master，而不用手工切换到server分支后再执行衍合操做——git rebase [主分支] [特性分支]命令会先取出特性分支server，而后在主分支master上重演

$ git rebase master server

　　因而，server的进度应用到master的基础上，以下图所示

　　而后就能够快进主干分支master了

$ git checkout master
$ git merge server

　　如今client和server分支的变化都已经集成到主干分支来了，能够删掉它们了。最终咱们的提交历史以下图所示

【衍合的风险】

　　要用衍合得遵照一条准则：一旦分支中的提交对象发布到公共仓库，就千万不要对该分支进行衍合操做

　　在进行衍合的时候，实际上抛弃了一些现存的提交对象而创造了一些相似但不一样的新的提交对象。若是你把原来分支中的提交对象发布出去，而且其余人更新下载后在其基础上开展工做，而稍后你又用git rebase抛弃这些提交对象，把新的重演后的提交对象发布出去的话，你的合做者就不得不从新合并他们的工做，这样当你再次从他们那里获取内容时，提交历史就会变得一团糟

　　下面咱们用一个实际例子来讲明为何公开的衍合会带来问题。假设你从一个中央服务器克隆而后在它的基础上搞了一些开发，提交历史以下图所示

　　如今，某人在C1的基础上作了些改变，并合并他本身的分支获得结果C6，推送到中央服务器。当你抓取并合并这些数据到你本地的开发分支中后，会获得合并结果C7

　　接下来，那个推送C6上来的人决定用衍合取代以前的合并操做；继而又用git push --force覆盖了服务器上的历史，获得C4'。而以后当你再从服务器上下载最新提交后，会获得

　　下载更新后须要合并，但此时衍合产生的提交对象C4'的SHA-1校验值和以前C4彻底不一样，因此Git会把它们看成新的提交对象处理，而实际上此刻你的提交历史C7中早已经包含了C4的修改内容，因而合并操做会把C7和C4'合并为C8

　　C8这一步的合并是早晚会发生的，由于只有这样你才能和其余协做者提交的内容保持同步。而在C8以后，你的提交历史里就会同时包含C4和C4'，二者有着不一样的SHA-1校验值，若是用git log查看历史，会看到两个提交拥有相同的做者日期与说明，使人费解。而更糟的是，当你把这样的历史推送到服务器后，会再次把这些衍合后的提交引入到中央服务器，进一步困扰其余人

　　这个例子中，出问题的责任方是那个发布了C6后又用衍合发布C4'的人，其余人会所以反馈双重历史到共享主干，从而混淆你们的视听

　　若是把衍合当成一种在推送以前清理提交历史的手段，并且仅仅衍合那些还没有公开的提交对象，就没问题。若是衍合那些已经公开的提交对象，而且已经有人基于这些提交对象开展了后续开发工做的话，就会出现叫人沮丧的麻烦

 

保存现场

　　软件开发中，bug就像屡见不鲜同样。有了bug就须要修复，在Git中，因为分支是如此的强大，因此，每一个bug均可以经过一个新的临时分支来修复，修复后，合并分支，而后将临时分支删除。

　　当你接到一个修复一个代号101的bug的任务时，很天然地，你想建立一个分支issue-101来修复它，可是，等等，当前正在dev上进行的工做尚未提交：

$ git status
# On branch dev
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       new file:   hello.py
#
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   readme.txt
#

　　并非不想提交，而是工做只进行到一半，还无法提交，预计完成还需1天时间。可是，必须在两个小时内修复该bug，怎么办？

　　幸亏，Git还提供了一个stash功能，能够把当前工做现场“储藏”起来，等之后恢复现场后继续工做

$ git stash
Saved working directory and index state WIP on dev: 6224937 add merge
HEAD is now at 6224937 add merge

　　如今，用git status查看工做区，就是干净的（除非有没有被Git管理的文件），所以能够放心地建立分支来修复bug。

　　首先肯定要在哪一个分支上修复bug，假定须要在master分支上修复，就从master建立临时分支

$ git checkout master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 6 commits.
$ git checkout -b issue-101
Switched to a new branch 'issue-101'

　　如今修复bug，须要把“Git is free software ...”改成“Git is a free software ...”，而后提交

$ git add readme.txt 
$ git commit -m "fix bug 101"
[issue-101 cc17032] fix bug 101
 1 file changed, 1 insertion(+), 1 deletion(-)

　　修复完成后，切换到master分支，并完成合并，最后删除issue-101分支

$ git checkout master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 2 commits.
$ git merge --no-ff -m "merged bug fix 101" issue-101
Merge made by the 'recursive' strategy.
 readme.txt |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
$ git branch -d issue-101
Deleted branch issue-101 (was cc17032).

　　如今，是时候接着回到dev分支

$ git checkout dev
Switched to branch 'dev'
$ git status
# On branch dev
nothing to commit (working directory clean)

　　工做区是干净的，刚才的工做现场存到哪去了？用git stash list命令看看：

$ git stash list
stash@{0}: WIP on dev: 6224937 add merge

　　一是用git stash apply恢复，可是恢复后，stash内容并不删除，你须要用git stash drop来删除；

　　另外一种方式是用git stash pop，恢复的同时把stash内容也删了

$ git stash pop
# On branch dev
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       new file:   hello.py
#
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   readme.txt
#
Dropped refs/stash@{0} (f624f8e5f082f2df2bed8a4e09c12fd2943bdd40)

　　再用git stash list查看，就看不到任何stash内容了

$ git stash list

　　能够屡次stash，恢复的时候，先用git stash list查看，而后恢复指定的stash，用命令

$ git stash apply stash@{0}

　　总结一下，修复bug时，咱们会经过建立新的bug分支进行修复，而后合并，最后删除；当手头工做没有完成时，先把工做现场git stash一下，而后去修复bug，修复后，再git stash pop，回到工做现场