转眼到第三节了，我们进入分支管理。
git领域里的分支可以理解为一个有安全保障的临时仓库，有时我们新修改了代码，突然发现有bug需要回到之前的版本，有时我们开发到一半，突然要出去一趟，如何安全保存当前代码成为了一
个痛点，这时候有个分支就ok了，我们每次修改代码都新建一个分支，在上面修改完了再与之前的版本合并，而原来的版本可以保存也可以合并，而中途有事也可以用stash命令进行保存。
接下来我们具体学习：
之前我们学过版本回退，每次提交，Git都把它们串成一条时间线，这条时间线就是一个分支。截止到目前，只有一条时间线，在Git里，这个分支叫主分支，即master分支。HEAD严格来说不是
指向提交，而是指向master，master才是指向提交的，所以，HEAD指向的就是当前分支。一开始的时候，master分支是一条线，Git用master指向最新的提交，再用HEAD指向master，就能确
定当前分支，HEAD其实就可以理解成C里面的二级指针。每次提交，master分支都会向前移动一步，这样，随着我们不断提交，master分支的线也越来越长。当我们创建新的分支，例如dev时
，Git就新建一个指针叫dev，指向master相同的提交，再把HEAD指向dev，就表示当前分支在dev上。那么从现在开始，对工作区的修改和提交就是针对dev分支了，比如新提交一次后，dev指
针往前移动一步，而master指针不变，这就实现了旧版本的保存，当我们完成dev上的工作并确定无误了，我们就可以将master与其合并，此时dev就完成了它的使命，我们可以删除它，于是我
们又只剩下master一个分支了。
值得一提的是，上述一切操作都是基于指针层面的，没有对文件进行修改，这是分支的一大亮点。（参考链接有详细的图解）
接下来具体上命令：
1.创建并切换至分支dev： git checkout -b dev
2.查看当前分支： git branch （会列出所有分支，当前分支前面会标一个*号）
3.在分支dev上修改并提交文件: git add readme.txt & git commit -m "branch test"
4.切换回master分支： git checkout master （注意此时打开readme.txt本地文件是看不到刚刚在dev上的修改的）
5.把dev上的工作结果合并到master上： git merge dev
6.删除dev分支： git branch -d dev
然而使用分支也不总是一帆风顺的，这里以合并分支时的冲突问题为例。
假设我们现在分别在master和feature1两个分支上都有了新的提交，就像这样：
（截图来自廖雪峰官方网站，下同）
显然现在master和feature1两个分支处于平行的关系，如果用命令git merge feature1合并二者则会发生冲突，打开readme.txt我们就可以看到了。
我们现在来解决冲突：
首先我们将readme.txt编辑成我们理想的样子，然后进行提交（注意是两步，先add后commit），于是现在的情况变成了这样：
（也可以用命令git log查看分支情况，只是bash上的图没有这个截图清晰）
最后我们删除feature1就OK了~
这是一种典型的手动解决冲突问题的情况，注意一定要解决好冲突问题再合并。
上述所有提到的合并其实都是一种强制快速合并（Fast forward），也就是说用master强制合并当前的dev分支，也就是说分支dev同时被删除了，你可能会说，master合并过来不也就和dev
一样的吗为什么不删掉dev呢，事实上，重要的不是dev所指的文件内容，而是它的分支信息，如何能做到保留它呢，我们用命令git merge --no-ff -m "merge with no-ff" dev 来合并dev就行
了，就像这样：
在团队工程中，每个人写完了自己的代码就会合并到团队工程中去，这种情况下，用保留当前分支的合并方法就显得十分重要了，假如之后发现了问题，你可以很轻松地回溯，查看bug的来源。
这一节内容有点太多了233，先歇会，下一节咱们从应用分支继续~