分支在实际中有什么用呢？假设你准备开发一个新功能，但是需要两周才能完成，第一周你写了50%的代码，如果立刻提交，由于代码还没写完，不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交，又存在丢失每天进度的巨大风险。
现在有了分支，就不用怕了。你创建了一个属于你自己的分支，别人看不到，还继续在原来的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样，既安全，又不影响别人工作。
创建与合并分支
在git里，有一条master主分支。一开始的时候，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分支：
首先，创建dev分支，然后切换到dev分支：
$ git checkout -b dev Switched to a new branch 'dev'
git checkout -b dev 相当于git branch dev(创建dev分支)和git checkout dev（切换到dev分支）。
然后，用git branch命令查看当前分支：
$ git branch * dev master
git branch命令会列出所有分支，当前分支前面会标一个*号。
比如在readme.txt里面改了一行东西，改好了提交：
$ git add readme.txt $ git commit -m "branch test" [dev fec145a] branch test 1 file changed, 1 insertion(+)
dev已经干完该干完的活了，切回master主分支：
git checkout master
现在，我们把dev分支的工作成果合并到master分支上：
$ git merge dev
最后，删除dev分支
git branch -d dev
因为创建、合并和删除分支非常快，所以Git鼓励你使用分支完成某个任务，合并后再删掉分支，这和直接在master分支上工作效果是一样的，但过程更安全。
解决冲突
假如把主分支master的内容和dev分支同时修改内容。这样在合并的时候就会出现冲突，这种情况下，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.
上面告诉我们必须要手动改文件的内容才能解决冲突，没办法只能到内容里面把冲突的地方修改一下。
然后再提交：
$ git add readme.txt $ git commit -m "conflict fixed" [master 59bc1cb] conflict fixed
用带参数的git log也可以看到分支的合并情况：
$ git log --graph --pretty=oneline --abbrev-commit * 59bc1cb conflict fixed | | * 75a857c AND simple * | 400b400 & simple |/ * fec145a branch test
最后，删除feature1分支：
$ git branch -d feature1