分支管理
分⽀就是科幻电影⾥⾯的平⾏宇宙，当你正在电脑前努⼒学习C++的时候，另⼀个你正在另⼀个平⾏宇宙⾥努⼒学习JAVA。
在版本回退⾥，每次提交，Git都把它们串成⼀条时间线，这条时间线就可以理解为是⼀个分⽀。截⽌到⽬前，只有⼀条时间线，在Git⾥，这个分⽀叫主分⽀，即master分⽀。
HEAD严格来说不是指向提交，⽽是指向master，master才是指向提交的，所以，HEAD指向的就是当前分⽀。
每次提交，master分⽀都会向前移动⼀步，这样，随着你不断提交，master分⽀的线也越来越⻓,⽽HEAD只要⼀直指向master分⽀即可指向当前分⽀。
创建分支
Git⽀持查看或创建其他分⽀，创建第⼀个分⽀ dev
当我们创建新的分⽀后，Git新建了⼀个指针叫dev， * 表⽰当前 HEAD 指向的分⽀是 master 分⽀。另外，可以通过⽬录结构发现，新的 dev 分⽀
发现⽬前dev和master指向同⼀个修改。并且也可以验证下HEAD⽬前是指向 master 的。
切换分支
切换到dev分⽀下进⾏开发，使⽤ git checkout 命令即可完成切换
HEAD已经指向了dev，就表⽰已经成功的切换到了dev
在 dev 分⽀下修改ReadMe⽂件，新增⼀⾏内容，并进⾏⼀次提交操作
现在，dev分⽀的⼯作完成，切换回master分⽀
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 分⽀各⾃都分别有新的提交
发现ReadMe⽂件有冲突后，可以直接查看⽂件内容，要说的是Git会⽤
<<<<<<<，=======，>>>>>>>来标记出不同分⽀的冲突内容
此时我们必须要⼿动调整冲突代码，并需要再次提交修正后的结果
⽤带参数的gitlog也可以看到分⽀的合并情况
合并模式
常合并分⽀时，如果可能，Git会采⽤ Fast forward 模式。还记得如果我们采⽤ Fast forward 模式之后
在这种 Fast forward 模式下，删除分⽀后，查看分⽀历史时，会丢掉分⽀信息，看不出来最新提交到底是merge进来的还是正常提交的。
但在合并冲突部分，我们也看到通过解决冲突问题，会再进⾏⼀次新的提交，得到的最终状态为
那么这就不是 Fast forward 模式了，这样的好处是，从分⽀历史上就可以看出分⽀信息。例如已经删除了在合并冲突部分创建的 dev1 分⽀，但依旧能看到master其实是由其他分⽀合并得到
Fastfoward模式，看不出来是merge进来的还是master自己提交的
Git⽀持强制禁⽤ Fast forward 模式，那么就会在merge时⽣成⼀个新的 commit ，这样，从分⽀历史上就可以看出分⽀信息
--no-ff 参数，表⽰禁⽤ Fast forward 模式。禁⽤ Fast forward 模式后合并会创建⼀个新的 commit ，所以加上 -m 参数，把描述写进去
不使⽤ Fast forward 模式，merge后就像这样
所以在合并分⽀时，加上 --no-ff 参数就可以⽤普通模式合并，合并后的历史有分⽀，能看出来曾经做过合并，⽽ fast forward 合并就看不出来曾经做过合并
分支策略
⾸先，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 分⽀
⽤ git stash list 命令可以查看工作现场
⽤ git stash pop 命令可以恢复现场，恢复的同时会把stash也删了
另外，恢复现场也可以采⽤ git stash apply 恢复，但是恢复后，stash内容并不删除，需要⽤ git stash drop 来删除；
可以多次stash，恢复的时候，先⽤ git stash list 查看，然后恢复指定的stash，⽤命令git stash apply stash@{0} ,
修复bug的内容，并没有在 dev2 上显⽰
Master 分⽀⽬前最新的提交，是要领先于新建 dev2 时基于的 master 分⽀的提交的，所以在 dev2 中当然看不⻅修复bug的相关代码。
最终⽬的是要让 master 合并 dev2 分⽀的，那么正常情况下我们切回 master 分⽀直接合并即可，但这样其实是有⼀定⻛险的。
是因为在合并分⽀时可能会有冲突，⽽代码冲突需要我们⼿动解决（在 master 上解决）。我们⽆法保证对于冲突问题可以正确地⼀次性解决掉，因为在实际的项⽬中，代码冲突不只⼀两⾏那么简单，有可能⼏⼗上百⾏，甚⾄更多，解决的过程中难免⼿误出错，导致错误的代码被合并到 master 上。
此时的状态为
解决这个问题的⼀个好的建议就是：最好在⾃⼰的分⽀上合并下 master ，再让 master 去合并dev ，这样做的⽬的是有冲突可以在本地分⽀解决并进⾏测试，⽽不影响 master 。
强制删除分支
软件开发中，总有⽆穷⽆尽的新的功能要不断添加进来。
添加⼀个新功能时，肯定不希望因为⼀些实验性质的代码，把主分⽀搞乱了，所以，每添加⼀个新功能，最好新建⼀个分⽀，我们可以将其称之为 feature 分⽀，在上⾯开发，完成后，合并，最后，删除该 feature 分⽀。
可是，如果正在某个 feature 分⽀上开发了⼀半，被产品经理突然叫停，说是要停⽌新功能的开发。虽然⽩⼲了，但是这个 feature 分⽀还是必须就地销毁，留着⽆⽤了。这时使⽤传统的 git branch -d 命令删除分⽀的⽅法是不⾏的。
