在版本回退里，你已经知道，每次提交，Git都把它们串成一条时间线，这条时间线就可以理解为是一个分支。截止到目前，只有一条时间线，在Git里，这个分支叫主分支，即master分支。
再来理解一下HEAD，HEAD严格来说不是指向提交，而是指向master，master才是指向提交的，所以，HEAD指向的就是当前分支。
每次提交，master分⽀都会向前移动⼀步，这样，随着你不断提交，master分支的线也越来越⻓,⽽HEAD只要⼀直指向master分支即可指向当前分支。
创建分支
git branch:查看当前本地所有分支
git branch dev:新建分支dev*表⽰当前 HEAD 指向的分支是 master 分
支。另外，可以通过⽬录结构发现，新的 dev 分支和master指向同⼀个修改。:
切换分支
使⽤git checkout 命令完成分支切换。
在 dev 分支下修改ReadMe⽂件，新增⼀行内容，并进⾏⼀次提交操作：
切换回master发现新增的内容不见了，在dev分支上内容还在。为什么会这样呢？我们看看dev和master的分支指向，发现两者指向的提交是不同的。
因为我们是在dev分支上提交的，⽽master分支此刻的提交点并没有变，此时的状态如下：
当切换到master分⽀时，HEAD就指向了master，当然看不到提交！
合并分支
为了能在master主分支上看到新的提交，就需要将dev分支合并到master分支，示例如下：
git merge命令用于合并指定分支。合并后master就能看到dev分支提交的内容了。此时状态如下：
Fast-forward代表"快进模式"，也就是直接把master指向dev的当前提交，所以合并速度⾮常快。当然，也不是每次合并都能Fast-forward。
删除分支
合并完成后,dev分支对于我们来说就没用了，那么dev分支就可以被删除掉，注意如果当前正处于某分支下，就不能删除当前分支，如：
⽽可以在其他分支下删除当前分支，如：
此时状态如下：
因为创建、合并和删除分支非常快，所以Git鼓励你使用分支完成某个任务，合并后再删掉分支，这和直接在master分支上工作效果是一样的，但过程更安全。
合并冲突
可是，在实际分支合并的时候，并不是想合并就能合并成功的，有时候可能会遇到代码冲突的问题。
为了演示这问题，创建一个新的分支dev1，并切换至目标分支，我们可以使用git checkout -b dev1 一步完成创建并切换的动作，示例如下：
在dev1分支下修改ReadMe文件并提交：
切换至master分支，修改ReadMe文件内容：
现在， master 和 dev1 分支各⾃都分别有新的提交，变成了这样：
这种情况下，Git只能试图把各⾃的修改合并起来，但这种合并就可能会有冲突，如下：
发现ReadMe⽂件有冲突后，可以直接查看⽂件内容，要说的是Git会⽤标记出不同分⽀的冲突内容，如下:
此时我们必须要手动调整冲突代码，并需要再次提交修正后的结果！！
到这⾥冲突就解决完成，此时的状态变成了：
⽤带参数的git log也可以看到分⽀的合并情况：
最后，不要忘记dev1分⽀使⽤完后就可以删除了：
分支管理策略
通常合并分支时，如果可能，Git会采用Fast forward模式。我们采用Fast forward模式之后，形成的合并结果：
在这种Fast forward模式下，删除分支后，查看分支历史时会丢掉分支信息，看不出来最新提交到底是merge进来的还是正常提交的。
但在合并冲突部分，我们也看到通过解决冲突问题，会再进行一次新的提交，得到的最终状态为：
那么这就不是Fast forward模式了，这样的好处是，从分支历史上就可以看出分支信息。例如我们现在已经删除了在合并冲突部分创建的dev1分支，但依旧能看到master其实是由其他分支合并得到：
Git支持我们强制禁用Fast forward模式，那么就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息。
下面我们实战一下--no-ff方式的git merge。首先，创建新的分支dev2:
切回master分支，开始合并：
请注意 --no-ff 参数，表示禁用 Fast forward 模式。禁用 Fast forward 模式后合并会创建一个新的 commit ，所以加上 -m 参数，把描述写进去。
合并后，查看分支历史：
分支策略
在实际开发中，我们应该按照几个基本原则进行分支管理：
首先，master分支应该是非常稳定的，仅用来发布新版本，平时不能在上面干活；干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；
所以，团队合作的分支看起来就像这样：
bug分支
假如我们现在正在dev2分支上进行开发，开发到一半，突然发现master分支上面有bug需要解决。在Git中，每个bug都可以通过一个新的临时分支来修复，修复后合并分支，然后将临时分支删除。
但现在dev2的代码在工作区中开发了一半，还无法提交怎么办？例如：
Git提供了 git stash 命令，可以将当前的⼯作区信息进⾏储藏，被储藏的内容可以在将来某个时间恢复出来。
用 git status 查看工作区是干净的（除非有没有被Git管理的文件），因此可以放心地创建分支来修复bug。
储藏 dev2 工作区之后，由于我们要基于master分支修复bug，所以需要切回 master 分支，再新建临时分支来修复bug，示例如下：
修复完成后，切换到 master 分支，并完成合并，最后删除 fix_bug 分支：
继续回到dev2 分支进行开发，工作现场还在，Git把stash内容存在某个地方了，但需要恢复一下。我们可以使用git stash pop 命令，恢复的同时会把stash也删了，示例如下：
另外，恢复现场也可以采用 git stash apply 恢复，但恢复后stash内容并不删除，你需要用 git stash drop 来删除；
可以多次stash，恢复的时候，先用 git stash list 查看，然后恢复指定的stash，用命令 git stash apply stash@{0}。
恢复完代码之后我们便可以继续完成开发，开发完成后便可以进行提交，例如：
此时：
我们的最终目的是要让 master 合并 dev2 分支的，那么正常情况下我们切回 master 分支直接合并即可，但这样其实是有一定风险的。
因为在合并分支时可能会有冲突，而代码冲突需要我们手动解决（在 master 上解决）。我们无法保证对于冲突问题可以正确地一次性解决掉，因为在实际的项目中，代码冲突不只一两行那么简单，有可能几十上百行甚至更多，解决的过程中难免手误出错，导致错误的代码被合并到 master 上。
此时的状态为：
解决这个问题的一个建议是：最好在自己的分支上合并下 master，再让 master 去合并 dev，这样做的目的是有冲突可以在本地分支解决并进行测试，而不影响 master。此时的状态为：
示例如下：(要说明的是，以下演示的merge操作，没有使用--no-ff，但上述的图示是禁用Fast forward模式后得出的，主要是为了方便解释问题。)
删除临时分支
添加一个新功能时，肯定不希望因为一些实验性质的代码，把主分支搞乱了，所以，每添加一个新功能最好新建一个分支，我们可以将其称之为feature分支，在上面开发，完成后，合并，最后删除该feature分支。
可是，如果我们今天正在某个feature分支上开发了一半，被产品经理突然叫停，说是要停止新功能的开发。虽然白干了，但是这个feature分支还是必须就地销毁，留着无用了。这时使用传统的git branch -d 命令删除分支的方法是不行的。演示如下：
强制删除一个没有合并的 feature 分支 :
