Git学习使用（五）：分支管理
创建和合并分支
在版本回退里，你已经知道，每次提交，Git都把它们串成一条时间线，这条时间线就是一个分支。截止到目前，只有一条时间线，在Git里，这个分支叫主分支，即master分支。HEAD严格来说不是指向提交，而是指向master，master才是指向提交的，所以，HEAD指向的就是当前分支。
一开始的时候，master分支是一条线，Git用master指向最新的提交，再用HEAD指向master，就能确定当前分支，以及当前分支的提交点：
每次提交，master分支都会向前移动一步，这样，随着你不断提交，master分支的线也越来越长：
当我们创建新的分支，例如dev时，Git新建了一个指针叫dev，指向master相同的提交，再把HEAD指向dev，就表示当前分支在dev上：
Git创建一个分支很快，因为除了增加一个dev指针，改改HEAD的指向，工作区的文件都没有任何变化！
不过，从现在开始，对工作区的修改和提交就是针对dev分支了，比如新提交一次后，dev指针往前移动一步，而master指针不变：
假如我们在dev上的工作完成了，就可以把dev合并到master上。Git怎么合并呢？最简单的方法，就是直接把master指向dev的当前提交，就完成了合并：
所以Git合并分支也很快！就改改指针，工作区内容也不变！
合并完分支后，甚至可以删除dev分支。删除dev分支就是把dev指针给删掉，删掉后，我们就剩下了一条master分支：
接下来我们就试试！
首先，我们创建dev分支，然后切换到dev分支：
$git checkout -b dev
切换到一个新分支 'dev'git checkout命令加上-b参数表示创建并切换，相当于以下两条命令：
$ git branch dev
$ git checkout dev
切换到一个分支 'dev'然后，用git branch命令查看当前分支：
$ git branch
* dev
mastergit branch命令会列出所有分支，当前分支前面会标一个*号。
然后，我们就可以在dev分支上正常提交，比如对Readme.txt做个修改，加上一行：
Creating a new branch is quick.
然后提交：
$git add Readme.txt
$git commit -m 'branch test'
[dev cd5c5e6] branch test
1 file changed, 2 insertions(+), 1 deletion(-)可以看出我们已经提交到了dev分支。
如果想要切换回master分支可以使用git branch命令切换回去。
$git checkout master
切换到分支 'master'
您的分支与上游分支 'origin/master' 一致。切换回master分支后，再查看一个Readme.txt文件，刚才添加的内容不见了！因为那个提交是在dev分支上，而master分支此刻的提交点并没有变：
现在，我们把dev分支的内容合并到master分支上：
$git merge dev
更新 27aac89..cd5c5e6
Fast-forward
Readme.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)git merge命令用于合并指定分支到当前分支。合并后，再查看Readme.txt的内容，就可以看到，和dev分支的最新提交是完全一样的。
注意到上面的Fast-forward信息，Git告诉我们，这次合并是“快进模式”，也就是直接把master指向dev的当前提交，所以合并速度非常快。
当然，也不是每次合并都能Fast-forward，我们后面会讲其他方式的合并。
合并完成后，就可以放心地删除dev分支了：
git branch -d dev
已删除分支 dev（曾为 cd5c5e6）。删除后，查看branch，就只剩下master分支了!
冲突
合并分支往往也不是一帆风顺的，那我们会面对那些问题呢？
先准备一个新分支：
$git checkout -b new
切换到一个新分支 'new'更改Readme.txt文件，并提交到new分支。方法我们之前已经说过了！
接着，切换到master:
$git checkout master
切换到分支 'master'
您的分支领先 'origin/master' 共 1 个提交。
（使用 "git push" 来发布您的本地提交）继续更改master分支的Readme.txt文件，使其与new分支的不同，然后提交。
现在，master分支和feature1分支各自都分别有新的提交，变成了并列的：
这种情况下，Git无法执行“快速合并”，只能试图把各自的修改合并起来，但这种合并就可能会有冲突，我们试试看：
$git merge new
自动合并 Readme.txt
冲突（内容）：合并冲突于 Readme.txt
自动合并失败，修正冲突然后提交修正的结果。Git告诉我们，Readme.txt文件存在冲突，必须手动解决冲突后再提交。git status也可以告诉我们冲突的文件：
$git status
位于分支 master
您的分支领先 'origin/master' 共 2 个提交。
（使用 "git push" 来发布您的本地提交）
您有尚未合并的路径。
（解决冲突并运行 "git commit"）
（使用 "git merge --abort" 终止合并）
未合并的路径：
（使用 "git add <文件>..." 标记解决方案）
双方修改： Readme.txt
修改尚未加入提交（使用 "git add" 和/或 "git commit -a"）查看Readme.txt文件，发现修改的内容变成了这样：
<<<<<<< HEAD
Creating a new branch is quick & simple.
=======
Creating a new branch is quick AND simple.
>>>>>>> new
Git用<<<<<<<，=======，>>>>>>>标记出不同分支的内容，我们修改后保存，并提交。
现在，master分支和new分支变成了下图所示：
用带参数的git log也可以看到分支的合并情况：
$git log --graph --pretty=oneline --abbrev-commit
* 0dda1c4 conflict fixed
|\
| * 80b582d AND simple
* | 488ec2b & simple
|/
....最后删除new分支。
分支管理策略
通常，合并分支时，如果可能，Git会用Fast forward模式，但这种模式下，删除分支后，会丢掉分支信息。
如果要强制禁用Fast forward模式，Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息。
下面我们实战一下--no-ff方式的git merge：
首先，仍然创建并切换dev分支：
$ git checkout -b dev修改Readme.txt文件，并提交一个新的commit：
git add Readme.txt
git commit -m 'add merge'
[dev 877c785] add merge
1 file changed, 1 insertion(+)现在，我们切换回master：
$git checkout master
切换到分支 'master'
您的分支领先 'origin/master' 共 4 个提交。准备合并dev分支，请注意--no-ff参数，表示禁用Fast forward：
$git merge --no-ff -m 'merge with no-ff' dev
Merge made by the 'recursive' strategy.
Readme.txt | 1 +
1 file changed, 1 insertion(+)因为本次合并要创建一个新的commit，所以加上-m参数，把commit描述写进去。
合并后，我们用git log看看分支历史：
$git log --graph --pretty=oneline --abbrev-commit
* ae4725a merge with no-ff
|\
| * 877c785 add merge
|/
* 0dda1c4 conflict fixed不使用Fast forward模式，merge后就像这样：
分支策略
首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；
那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；
你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。
所以，团队合作的分支看起来就像这样：
合并分支时，加上–no-ff参数就可以用普通模式合并，合并后的历史有分支，能看出来曾经做过合并，而fast forward合并就看不出来曾经做过合并。