Svn 中也有分支管理，但是很 low，Git 的分支管理非常强大，本文先不去说分支管理内部到底怎么做的，我们先来看看 Git 中最基本的分支管理操作。
本文是 Git 系列的第四篇，了解前面的文章有助于更好的理解本文：
1.Git 概述
2.Git 基本操作
3.Git 中的各种后悔药
分支的必要性
小伙伴们都知道，我们在完成一个项目时，不可能是“单线程”开发的，很多时候任务是并行的，举个栗子：项目 2.0 版本上线了，现在要着手开发 3.0 版本，同时 2.0 版本可能还有一些 bug 需要修复，这些 bug 修复之后我们可能还会发 2.1，2.2，2.3 这些版本，我们不可能等所有 bug 都修复完了再去开发 3.0 版本，修复 2.0 的 bug 和开发 3.0 的新功能是两个并行的任务，这个时候我们 3.0 的功能开发直接在 master 分支上进行肯定不合适，我们要保证有一个稳定，可以随时发版本的分支存在（一般情况下这个角色由 master 分支来扮演），此时我们就可以灵活的使用 Git 中的分支管理功能：
- 创建一个长期分支用来开发 3.0 功能，假设这个分支的名字就叫 v3，我们在 v3 上添加新功能，并不断测试，当 v3 稳定后，将 v3 合并到 master 分支上。
- 创建一个特性分支用来修复 2.0 的 bug ，一旦 bug 修复成功，就将该分支合并到 master 上，一旦发现新 bug ，就立马再创建分支进行修复，修复成功之后再合并。
以上两个步骤同步进行，这在 Svn 中简直是不可想象的，因为 Svn 的分支管理太 low，而 Git 能够让我们做到随心所欲的创建、合并和删除分支。
查看分支
我们可以通过 git branch 命令来查看当前仓库有哪些分支，而我们处于哪一个分支中，如下：
这里显示当前仓库只有一个 master 分支，这是 git 默认创建出来的，master 前面的 * 表示我们当前处于这一个分支中。
分支创建和切换
我们可以利用 git branch <分支名> 命令来创建一个分支，然后利用 git checkout <分支名> 来切换分支，如下：
如果小伙伴觉得这样太麻烦，可以通过 git checkout -b <分支名> 来一步到位，创建并切换分支，如下：
也可以通过 git checkout - 命令来切换回上一个分支，如下：
分支合并
现在我切换到 fa 分支中，由于 fa 分支是从 master 分支中创建出来的，所以此时 fa 分支的内容和 master 分支的内容是一致的，然后我在 fa 分支中向 git01.txt 文件添加一行内容并提交，此时 fa 分支中的 git01.txt 和 master 分支中 git01.txt 的内容就不相同了，具体操作如下：
上图展示了此时 master 分支和 fa 分支的不同，现在我通过 git merge --no-ff <分支名> 命令将 fa 分支合并到 master 分支上。其中 –no-ff 表示强行关闭 fast-forward 方式， fast-forward 方式表示当条件允许时， git 直接把 HEAD 指针指向合并分支的头，完成合并，这种方式合并速度快，但是在整个过程中没有创建 commit，所以如果当我们删除掉这个分支时就再也找不回来了，因此在这里我们将之关闭。
想要合并分支，我们先切换到 master 分支上，然后执行 git merge --no-ff fa 命令即可完成分支合并，如下图：
合并成功后，我们看到 master 分支上的 git01.txt 上已经有了 fa 分支中的内容了。
以图表方式查看分支
我们可以通过 git log --graph 命令来直观的查看分支的创建和合并等操作，如下图：
分支衍合
所谓的分支衍合其实也是分支合并的一种方式，下面我们就来看看这个分支衍合到底是什么样的。现在我的 master 分支的内容和 fa 分支的内容是保持一致的，fa 是从 master 中创建出来的，如下图：
现在我向 fa 和 master 中各自做一次提交，如下图：
此时我们执行如下两条命令将两个分支合并：
1 | $ git checkout fa |
rebase 命令在执行的过程中会首先把 fa 中的每个 commit 取消，并且将之保存为临时 patch ，再将 fa 分支更新为最新的 master 分支，然后再把那些临时的 patch 应用到 fa 上，此时 fa 分支将指向新创建的 commit 上，那些老的 commit 将会被丢弃，这些被丢弃的 commit 在执行 git gc 命令时会被删除。合并后的分支如下图：
上面的 git rebase master 命令在执行的过程中有可能会发生冲突，发生冲突时我们有两种方案，一种直接退回到之前的状态，另一种就是解决冲突继续提交。
退回到之前的状态
我们可以通过如下命令来回到之前的状态：
1 | $ git rebase --abort |
解决冲突
不过大多数情况下我们都是要解决冲突的，解决之后继续提交。此时我们用编辑器打开冲突的文件，看到的内容可能是这样的：
======上面的是 HEAD 中的内容，下面的是要合并的内容，根据自己的需求编辑文件，编辑完成之后，通过如下两条命令继续完成合并：
1 | $ git add git01.txt |
如下图：
冲突解决
我们前面提到了在分支衍合时出现冲突的解决方案，其实普通的合并也有可能出冲突，出现冲突很正常，解决就是了，git merge 合并分支时如果出现冲突还是先重新编辑冲突文件，编辑完成之后，再执行 git add 和 git commit 即可。
好了，分支管理我们就先说这么多，有问题欢迎留言讨论。
参考资料：
1.《GitHub入门与实践》
2.《Pro Git》
