Git存储机制
在理解Git分支的运行机制之前，要了解一下Git是如何存储数据的。
当使用 git commit 新建一个提交对象前，Git 会先计算每一个子目录的校验和，然后在 Git 仓库中将这些目录保存为树（tree）对象。之后 Git 创建的提交对象，除了包含相关提交信息以外，还包含着指向这个树对象（项目根目录）的指针，如此它就可以在将来需要的时候，重现此次快照的内容了。
单个提交对象在仓库中的数据结构如下图所示：
上图中，Git 仓库中有五个对象：三个表示文件快照内容的 blob 对象；一个记录着目录树内容及其中各个文件对应 blob 对象索引的 tree 对象；以及一个包含指向 tree 对象（根目录）的索引和其他提交信息元数据的 commit 对象。
作些修改后再次提交，那么这次的提交对象会包含一个指向上次提交对象的指针，即下图中的 parent 对象。两次提交后，仓库历史会变成下图的样子：
上图展现了多个提交对象之间的链接关系。
什么是Git分支
Git 中的分支，其实本质上仅仅是个指向 commit 对象的可变指针。Git 会使用 master 作为分支的默认名字。在若干次提交后，你其实已经有了一个指向最后一次提交对象的 master 分支，它在每次提交的时候都会自动向前移动。
如下图所示：
Git 创建一个新的分支就等同于创建一个新的分支指针。
比如我们要创建一个名为testing的分支，我们可以使用git branch 命令：
$ git branch testing
这会在当前 commit 对象上新建一个分支指针，如下图所示：
Git会保存着一个名为 HEAD 的特别指针，用来记录当前当前你正在哪个分支上工作。
运行 git branch 命令，仅仅是建立了一个新的分支，但不会自动切换到这个分支中去，所以在上个例子中，我们依然还在 master 分支里工作，如图：
要切换到其他分支，可以执行 git checkout 命令。我们现在转换到新建的 testing 分支：
$ git checkout testing
这样 HEAD 就指向了 testing 分支：
此时，如果我们再提交一次：
$ vim test.rb
$ git commit -a -m 'made a change'
提交后的结果示意图如下：
我们会发现，每次提交后 HEAD 随着当前所在分支一起向前移动，testing 分支向前移动了一格，而 master 分支仍然指向原先 git checkout 时所在的 commit 对象。
现在我们回到 master 分支看看：
$ git checkout master
这条命令做了两件事。它把 HEAD 指针移回到 master 分支，并把工作目录中的文件换成了 master 分支所指向的快照内容。也就是说，现在开始所做的改动，将始于本项目中一个较老的版本。它的主要作用是将 testing 分支里作出的修改暂时取消，这样你就可以向另一个方向进行开发。
我们作些修改后再次提交：
$ vim test.rb
$ git commit -a -m 'made other changes'
结果如下图所示：
现在我们的项目提交历史产生了分叉，因为刚才我们创建了一个分支，转换到其中进行了一些工作，然后又回到原来的主分支进行了另外一些工作。这些改变分别孤立在不同的分支里：我们可以在不同分支里反复切换，并在时机成熟时把它们合并到一起。而所有这些工作，仅仅需要 branch 和 checkout 这两条命令就可以完成。
分支的新建与合并
我们假设一个这样的情景，假设你正在项目中愉快地工作，并且已经提交了几次更新，如下图：
此时你突然接到一个电话说有个很严重的问题需要紧急修补，利用Git分支，一个很好的做法是：
- 返回到原先已经发布到生产服务器上的分支。
- 为这次紧急修补建立一个新分支，并在其中修复问题。
- 通过测试后，回到生产服务器所在的分支，将修补分支合并进来，然后再推送到生产服务器上。
- 切换到之前实现新需求的分支，继续工作。
因此，比如你要修补问题追踪系统上的 #53 问题，你建立了一个名为 iss53的分支。
要新建并切换到该分支，运行 git checkout 并加上 -b 参数：
$ git checkout -b iss53
Switched to a new branch "iss53"
这相当于执行下面这两条命令：
$ git branch iss53
$ git checkout iss53
此时，状态如下：
接着你开始尝试修复问题，在提交了若干次更新后，iss53 分支的指针也会随着向前推进，因为它就是当前分支（换句话说，当前的 HEAD 指针正指向 iss53）如下图：
然而此时，你又接到一个紧急电话，原先发布的系统需要需要马上修补另一个问题。
有了 Git ，我们就不需要同时发布这个补丁和 iss53 里作出的修改，也不需要在创建和发布该补丁到服务器之前花费大力气来复原这些修改。唯一需要的仅仅是切换回 master 分支。
$ git checkout master
Switched to branch "master"
此时工作目录中的内容和你在解决问题 #53 之前一模一样，你可以集中精力进行紧急修补。这一点值得牢记：Git 会把工作目录的内容恢复为检出某分支时它所指向的那个提交对象的快照。它会自动添加、删除和修改文件以确保目录的内容和你当时提交时完全一样。
接下来，你得进行紧急修补。我们创建一个紧急修补分支 hotfix 来开展工作，直到搞定，如下图所示：
$ git checkout -b 'hotfix'
Switched to a new branch "hotfix"
$ vim index.html
$ git commit -a -m 'fixed the broken email address'
[hotfix]: created 3a0874c: "fixed the broken email address"
1 files changed, 0 insertions(+), 1 deletions(-)
修补完成后，我们只需要回到 master 分支并把它合并进来，然后发布到生产服务器。
分支的合并
用 git merge 命令来进行合并：
$ git checkout master
$ git merge hotfix
Updating f42c576..3a0874c
Fast forward
README | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
合并时出现了“Fast forward”的提示。由于当前 master 分支所在的提交对象是要并入的 hotfix 分支的直接上游，Git 只需把 master 分支指针直接右移。换句话说，如果顺着一个分支走下去可以到达另一个分支的话，那么 Git 在合并两者时，只会简单地把指针右移，因为这种单线的历史分支不存在任何需要解决的分歧，所以这种合并过程可以称为快进（Fast forward）。
现在最新的修改已经在当前 master 分支所指向的提交对象中了，可以部署到生产服务器上去了。合并之后，master 分支和 hotfix 分支指向同一位置。如下图所示：
在那个超级重要的修补发布以后，你想要回到被打扰之前的工作。由于当前 hotfix 分支和 master 都指向相同的提交对象，所以 hotfix 已经完成了历史使命，可以删掉了。
分支的删除
使用 git branch 的 -d 选项执行删除操作：
$ git branch -d hotfix
Deleted branch hotfix (3a0874c).
现在回到之前未完成的 #53 问题修复分支上继续工作：
$ git checkout iss53
Switched to branch "iss53"
$ vim index.html
$ git commit -a -m 'finished the new footer [issue 53]'
[iss53]: created ad82d7a: "finished the new footer [issue 53]"
1 files changed, 1 insertions(+), 0 deletions(-)
在问题 #53 相关的工作完成之后，可以合并回 master 分支。实际操作同前面合并 hotfix 分支差不多，只需回到 master 分支，运行 git merge 命令指定要合并进来的分支：
$ git checkout master
$ git merge iss53
Merge made by recursive.
README | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
这次合并操作的底层实现，并不同于之前 hotfix 的并入方式。因为这次你的开发历史是从更早的地方开始分叉的。由于当前 master 分支所指向的提交对象（C4）并不是 iss53 分支的直接祖先，Git 不得不进行一些额外处理。就此例而言，Git 会用两个分支的末端（C4 和 C5）以及它们的共同祖先（C2）进行一次简单的三方合并计算。Git 为分支合并自动识别出最佳的同源合并点。下图用红框标出了 Git 用于合并的三个提交对象：
这次，Git 没有简单地把分支指针右移，而是对三方合并后的结果重新做一个新的快照，并自动创建一个指向它的提交对象：
遇到冲突时的分支合并
如果在不同的分支中都修改了同一个文件的同一部分，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 查阅：
[master*]$ git status
index.html: needs merge
# On branch master
# 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)
#
# unmerged: index.html
#
任何包含未解决冲突的文件都会以未合并（unmerged）的状态列出。Git 会在有冲突的文件里加入标准的冲突解决标记，可以通过它们来手工定位并解决这些冲突。
当我们人为的将不同的地方修改成一样后，再次运行分支合并，并用 git commit 来完成这次合并提交。
分支的管理
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
要从该清单中筛选出你已经（或尚未）与当前分支合并的分支，可以用 --merge 和 --no-merged 选项。
比如用 git branch --merge 查看哪些分支已被并入当前分支。
$ git branch --merged
iss53
* master
之前我们已经合并了 iss53，所以在这里会看到它。一般来说，列表中没有 * 的分支通常都可以用 git branch -d 来删掉。原因很简单，既然已经把它们所包含的工作整合到了其他分支，删掉也不会损失什么。
用 git branch --no-merged 查看尚未合并的工作：
$ git branch --no-merged
testing
远程分支
我们经常使用的Git的多数情况，是使用的远程Git服务器，而不是本地使用Git。
所以我们经常遇到的分支情况，更多的是远程分支。
假设你们团队有个地址为 git.ourcompany.com 的 Git 服务器。如果你从这里克隆，Git 会自动为你将此远程仓库命名为 origin，并下载其中所有的数据，建立一个指向它的 master 分支的指针，在本地命名为 origin/master，但你无法在本地更改其数据。接着，Git 建立一个属于你自己的本地 master 分支，始于 origin 上 master 分支相同的位置，你可以就此开始工作。
如下图所示：
一次 Git 克隆会建立你自己的本地分支 master 和远程分支 origin/master，并且将它们都指向 origin 上的 master 分支。
如果你在本地 master 分支做了些改动，与此同时，其他人向 git.ourcompany.com 推送了他们的更新，那么服务器上的 master 分支就会向前推进，而于此同时，你在本地的提交历史正朝向不同方向发展。不过只要你不和服务器通讯，你的 origin/master 指针仍然保持原位不会移动：
可以运行 git fetch origin 来同步远程服务器上的数据到本地。该命令首先找到 origin 是哪个服务器（本例为 git.ourcompany.com），从上面获取你尚未拥有的数据，更新你本地的数据库，然后把 origin/master 的指针移到它最新的位置上，如下图所示：
推送本地分支
想和其他人分享某个本地分支，你需要把它推送到一个你拥有写权限的远程仓库。你创建的本地分支不会因为你的写入操作而被自动同步到你引入的远程服务器上，你需要明确地执行推送分支的操作。
如果你有个叫 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 [email protected]:schacon/simplegit.git
* [new branch] serverfix -> serverfix
它的意思是“上传我本地的 serverfix 分支到远程仓库中去，仍旧称它为 serverfix 分支”。通过此语法，你可以把本地分支推送到某个命名不同的远程分支：若想把远程分支叫作 awesomebranch，可以用 git push origin serverfix:awesomebranch 来推送数据。
接下来，当你的协作者再次从服务器上获取数据时，他们将得到一个新的远程分支 origin/serverfix，并指向服务器上 serverfix 所指向的版本。
值得注意的是，在 fetch 操作下载好新的远程分支之后，你仍然无法在本地编辑该远程仓库中的分支。换句话说，在本例中，你不会有一个新的 serverfix 分支，有的只是一个你无法移动的 origin/serverfix 指针。
如果要把该远程分支的内容合并到当前分支，可以运行 git merge origin/serverfix。如果想要一份自己的 serverfix 来开发，可以在远程分支的基础上分化出一个新的分支来：
$ git checkout -b serverfix origin/serverfix
Branch serverfix set up to track remote branch refs/remotes/origin/serverfix.
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 [分支名] [远程名]/[分支名]
$ git checkout --track origin/serverfix
Branch serverfix set up to track remote branch refs/remotes/origin/serverfix.
Switched to a new branch "serverfix"
要为本地分支设定不同于远程分支的名字，只需在第一个版本的命令里换个名字：
$ git checkout -b sf origin/serverfix
Branch sf set up to track remote branch refs/remotes/origin/serverfix.
Switched to a new branch "sf"
现在你的本地分支 sf 会自动将推送和抓取数据的位置定位到 origin/serverfix 了。
删除远程分支
如果不再需要某个远程分支了，可以使用git push [远程名] :[分支名]命令删除远程分支。如果想在服务器上删除 serverfix 分支，运行下面的命令：
$ git push origin :serverfix
To [email protected]:schacon/simplegit.git
- [deleted] serverfix