分支管理适用于当我们开发某个功能时，还未写完代码提交了一个未完成的代码库。而未完成的代码库会使整个工程无法运行。但是一次写完提交又存在丢失每天进度的巨大风险。
现在有了分支，就可以创建了一个属于自己的分支，其他人看不见，还继续在原来的分支上正常工作，而我们在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样，既安全，又不影响其他人工作。
创建与合并分支
原理介绍
在之前的版本回退里面我们可以发现每次提交，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分支：
实际操作
首先要创建分支，再切换到分支（有两种等效方式）
git checkout -b dev
git branch dev
git checkout dev
然后再查看当前分支
git branch
git branch命令会列出所有分支，当前分支前面会标一个
* 号。
然后，我们就可以在dev分支上正常提交，比如对readme.txt做个修改，然后提交
现在，dev分支的工作完成，就可以切换回master分支：
切换回master分支后，再查看一个readme.txt文件，刚才添加的内容消失了，这是因为刚才的提交是在dev分支上，而master分支此刻的提交点并没有变：
现在，把dev分支的工作成果合并到master分支上：
git merge dev
git merge命令用于合并指定分支到当前分支。合并后，再查看readme.txt的内容，就可以看到，和dev分支的最新提交是完全一样的。
注意：上面的Fast-forward，Git告诉我们，这次合并是“快进模式”，也就是直接把master指向dev的当前提交，所以合并速度非常快。
当然，也不是每次合并都能Fast-forward，还有其他的合并方式。
合并完成后，就可以放心地删除dev分支了：
git branch -d dev
这节的命令小结：
查看分支：
git branch
创建分支：
git branch <name>
切换分支：
git checkout <name>
创建+切换分支：
git checkout -b <name>
合并某分支到当前分支：
git merge <name>
删除分支：
git branch -d <name>
解决冲突
当合并分支的时候也会出现冲突的情况：两个分支都有新的提交
当Git无法自动合并分支时，就必须首先解决冲突。解决冲突后，再提交，合并完成。
用
git log --graph命令可以看到分支合并图。
接下来用一个实例来说明如何解决这个问题：
这种情况下，Git无法执行“快速合并”，只能试图把各自的修改合并起来，但这种合并可能会有冲突：
Git提示readme.txt文件存在冲突，必须手动解决冲突后再提交。
git status也可以告诉我们冲突的文件：
查看之前修改的文件，Git用<<<<<<<，=======，>>>>>>>标记出不同分支的内容
我们做修改后在提交
现在，master分支和feature1分支变成了下图所示：
用带参数的git log也可以看到分支的合并情况：
git log --graph --pretty=oneline --abbrev-commit
最后，删除feature1分支。
分支管理策略
通常，合并分支时，如果可能，Git会用Fast forward模式，但这种模式下，删除分支后，会丢掉分支信息。如果要强制禁用Fast forward模式，Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息。使用--no-ff方式的git merge
创建一个分支
修改readme.txt文件，并提交一个新的commit：
现在，切换回master：
准备合并dev分支，请注意
--no-ff 参数，表示禁用Fast forward：
因为本次合并要创建一个新的commit，所以加上-m参数，把commit描述写进去。
合并后，可以用git log看看分支历史：
可以看到，不使用Fast forward模式，merge后就像这样：
分支策略
在实际开发中，我们应该按照几个基本原则进行分支管理：
首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；
那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；
我们和其他人每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。
所以，团队合作的分支看起来就像这样：
Bug分支
在Git中可以通过分支来修复Bug：通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。
但在实际情况中会出现这种情况：在当前分支的工作还未完成的情况下，要优先进行Bug修复工作。
解决思路：将当前分支保存，新开一个分支修复Bug，最后回到保存的分支继续开发。
使用
git stash 命令保存当前现场
现在查看工作区就清理干净了
接下来就开始Bug修复工作然后提交
切换回master分支，合并，删除 issue-101 分支
最后回到之前的分支继续工作，但是工作区依然是空的
这里是因为工作现场还在，Git把stash内容存在某个地方了，但是需要恢复一下，有两个办法：
一是用
git stash apply恢复，但是恢复后，stash内容并不删除，需要用
git stash drop来删除；
另一种方式是用
git stash pop，恢复的同时把stash内容也删了：
可以多次stash，恢复的时候，先用git stash list查看，然后恢复指定的stash，用命令：
git stash apply stash@{0}
Feature分支
在分支开发过程中也会出现当前开发目标取消的情况：
在分支上开发完成并提交切回了工作分支准备合并
这时就是需要删除未合并的分支了
git branch -D
多人协作
当从远程仓库克隆时，实际上Git自动把本地的master分支和远程的master分支对应起来了，并且，远程仓库的默认名称是origin。
简略查看远程库的信息
git remote
详细查看远程库的信息
git remote -v
上面显示了可以抓取和推送的origin的地址。如果没有推送权限，就看不到push的地址。
推送分支
推送分支，就是把该分支上的所有本地提交推送到远程库。推送时，要指定本地分支，这样，Git就会把该分支推送到远程库对应的远程分支上：
git push origin master
如果要推送其他分支，比如dev，就改成：
git push origin dev
注意：并不是一定要把本地分支往远程推送
master分支是主分支，因此要时刻与远程同步；
dev分支是开发分支，团队所有成员都需要在上面工作，所以也需要与远程同步；
bug分支只用于在本地修复bug，就没必要推到远程了，除非老板要看看你每周到底修复了几个bug；
feature分支是否推到远程，取决于你是否和你的小伙伴合作在上面开发。
抓取分支