原文链接：http://www.cnblogs.com/BeginMan/p/3543240.html
分支的理念就是分身，就像孙悟空拔出猴毛变出很多跟自己一模一样的猴子，然后每个猴子做自己的事情互不干涉，等到所有猴子做完之后，猴子集合来合并劳动成果，然后悟空就把那些猴子猴孙门统统收回了。
你创建了一个属于你自己的分支，别人看不到，还继续在原来的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样，既安全，又不影响别人工作。
Git鼓励大量使用分支：
命令如下：
查看分支：git branch
创建分支：git branch name
切换分支：git checkout name
创建+切换分支：git checkout -b name
合并某分支到当前分支：git merge name
删除分支：git branch -d name
推荐阅读廖雪峰的Git教程
产生冲突的方式很多，常见的一种是创建一个分支并修改提交，然后回到主分支在修改提交同一个文件，然后“快速合并分支”就发生冲突了：
$ git merge feature1
Auto-merging readme.txt
CONFLICT (content): Merge conflict in readme.txt
Automatic merge failed; fix conflicts and then commit the result.
打开我修改的文件，可以发现显示如下：
<<<<<<< HEAD
在master上做出修改
=======
解决冲突
>>>>>>feature1<<<<<<< HEAD 表示主分支，主分支的修改是：“在master上做出修改”；>>>>>>feature1表示我创建的feature1分支。
解决办法就是手动处理冲突，这点跟SVN一样。处理之后在提交，然后删除分支即可。
通过廖雪峰的官方网站的git学习，让我清楚了明白git分支的策略：
在实际开发中，我们应该按照几个基本原则进行分支管理：
首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；
那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；
你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。
所以，团队合作的分支看起来就像这样：
关于no-ff:
上面我们使用的合并分支是fast forward，这种快速合并的模式，但是有个地方不好的就是不能显示历史信息，在以后开发中我不知道有哪些分支曾经合并过，所以最好使用 no-ff：no fast forward的合并方式，这种方式在合并的同时会生成一个新的commit，这样，从分支历史上就可以看出分支信息。
$ git merge --no-ff -m "merge with no-ff" dev在上一篇博客[git初体验（二）基础git文件操作]也总结了git的储蓄，所谓的储蓄就是针对以下的情况：
当你正在开发一个功能时，突然boss让你尽快修改一个bug，此时最紧急的是fix bug. 而正开发的功能尚未完善还不能提交，这个时候就会想到能不能将手头的工作隔离开，去单单解决bug，然后提交bug，然后在进行手头工作。
上面的案例就是git储蓄的出现：
git stash#把当前工作现场“储藏”起来开发一个新feature，最好新建一个分支；
如果要丢弃一个没有被合并过的分支，将丢失掉修改，可以通过git branch -D name强行删除。
参考：git创建与管理远程分支
1.远程分支就是本地分支push到服务器上的时候产生的。比如master就是一个最典型的远程分支（默认）
git push origin master2.随便创建分支，然后push到服务器就生成了远程分支
git checkout -b dev# 创建本地dev分支用于开发
git checkout -b bug# 创建本地bug分支用于bug处理
git checkout -b feature # 创建本地feature分支用于新功能开发
git push origin dev# 生成远程dev分支
git push origin bug
git push origin feature3.远程分支与本地分支区分。在服务器上拉取特定分支时要指定本地分支名称：
git checkout --track origin/dev
#注意该命令由于带有--track参数，所以要求git1.6.4以上！
这样git会自动切换到develop分支。4.同步本地远程分支
git fetch origin