所谓的分支管理其实就是就是同时可以有多条时间线在执行，最终合并为一个点，有点类似于多线程操作，这也正是git有别于其他版本控制软件的地方。
创建与合并分支
在版本回退里，你已经知道，每次提交，Git都把它们串成一条时间线，这条时间线就是一个分支。截止到目前，只有一条时间线，在Git里，这个分支叫主分支，即master分支。HEAD严格来说不是指向提交，而是指向master，master才是指向提交的，所以，HEAD指向的就是当前分支。
查看当前分支
git branch
在没有创建分支的情况下只有一个分支就是主分支，即master，在master前面的*号表示当前分支
创建分支
git branch dev1 //创建分支Dev
git checkout dev1 //切换分支到dev1
创建分支并切换到创建的分支
git checkout -b dev2
在dev2上操作
切回到master主分支
所以这是我们需要合并分支，修改的内容才能共享
合并分支
git merge dev2
上面的Fast-forward信息，Git告诉我们，这次合并是“快进模式”，也就是直接把master指向dev的当前提交，所以合并速度非常快。
删除分支
git branch -d dev2
因为创建、合并和删除分支非常快，所以Git鼓励你使用分支完成某个任务，合并后再删掉分支，这和直接在master分支上工作效果是一样的，但过程更安全。
解决冲突
版本控制软件不可避免的总会碰到版本冲突的问题，下面来看看怎么觉得冲突的
制造冲突
修改hello.txt文件
将dev分支上的内容进行add、commit操作
之后我们切换回master，在master上对文件进行修改，之后执行add、commit操作
之后进行合并分支
提示信息中告诉我们hello.txt文件存在冲突，须手动解决冲突后再提交。git status也可以告诉我们冲突的文件
解决冲突
先来查看冲突的文件
Git用<<<<<<<，=======，>>>>>>>标记出不同分支的内容<<<HEAD是指主分支修改的内容，>>>>>dev 是指dev上修改的内容
修改文件内容，和其他人进行协商，最后定谁提交的内容
查看合并情况
git log --graph --pretty=oneline --abbrev-commit
合并完之后最后删除掉分支dev即可
git branch -d dev
当Git无法自动合并分支时，就须首先解决冲突。解决冲突后，再提交，合并完成。解决冲突就是把Git合并失败的文件手动编辑为我们希望的内容，再提交。用git log --graph --pretty=oneline --abbrev-commit命令可以看到分支合并图。
分支策略
在实际开发中，我们应该按照几个基本原则进行分支管理：
首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。所以，团队合作的分支看起来就像这样：
