一、分支介绍
在版本控制过程当中，有时候需要同时推进多个任务，这样的话，就可以给每个任务创建单独的分支。
有了分支之后，对应的开发人员就可以把自己的工作从主线上分离出来，在做自己分支开发的时候，不会影响到主线分支的运行。
如图所示：
- 要开发个新功能，加个蓝色背景。那么从master上建一个分支feature-blue，开发完后，合回到master。
- 同时另外一个新功能也要做，给系统加个小游戏。同样上建一个分支feature-game进行开发。
- 发现feature-blue上有个bug，那么再从master上建一个热修复分支hot-fix进行bug修改，完事后合到master。
所以，在众多分支并行开发的时候，master上的代码是正常在服务器上运行的，不会被影响。
故使用分支有如下优点：
- 同时并行推进多个功能开发，提高开发效率。
- 各个分支在开发过程中，如果某一个分支开发失败，不会对其他分支造成影响。失败的分支可以删除掉重新开始即可。
二、分支操作
1. 查看分支
git branch -v
可以查看当前本地库有多少分支，其中*表示当前所在的分支。
2. 创建分支
git branch 分支名
创建完成后，再次查看分支，就可以看到新建的分支hot-fix。
3. 切换分支
当前所在还是master分支，我不想动master分支的内容，希望在hot-fix分支上进行修改，那么现在切换到目标分支。
git checkout 分支名
已经切换成功。
现在我可以在hot-fix分支下进行文件内容的修改了，我改动hello.txt的第一行内容。
然后git add hello.txt和git commit -m "hot-fix first commit" hello.txt。
用cat hello.txt可以查看文本内容，在git里 linux命令通用。
4. 合并分支
正常合并
在hot-fix修改完内容提交之后，现在切换回master分支，并且查看文件内容，发现还是原来的样子，没有受到影响。
现在我要把hot-fix上的内容合并到master上：
git merge 分支名
注意，这里是把命令行后输入的分支 合并到 当前所在分支，所以我先要切回到master上，才可以把hot-fix合过来。
合并完成，查看master分支上的文件内容，发现hot-fix上新增的内容已经合并了过来。
冲突合并
合并分支时，两个分支在同一个文件的同一个位置有两套完全不同的修改，这就产生了冲突，这也是团队协助中最常见的场景之一了。
此时，git无法决定使用哪一个，所以必须人为的决定新代码的内容。
现在来造成一个冲突的场景：
- 在
master分支，在hello.txt的最后一行末尾，增加新内容-"master test"。 - 切换到
hot-fix分支，在hello.txt的最后一行末尾，增加新内容-"hot-fix test"。 - 切换到
master分支，合并hot-fix分支。
提示自动合并失败，因为在hello.txt里面产生了冲突，此时查看git status，也可以看到提示。
OK，git处理不了，只能我们亲自出马了。此时可以打开文件vim hello.txt，会发现在文件里有冲突的提示。
有3个提示：
<<<<<<< HEAD，表示当前分支。=======，相当于分界线，等号与上面的HEAD之间，是当前分支的代码。等号与下面的 hot-fix，是要合并过来的代码。>>>>>>> hot-fix，要合并过来的分支。
现在我手动处理，希望2个分支的代码都保留，那么我留下这2行代码，把其余的提示信息去掉即可。
完成后进行git add hello.txt。
注意，在接下来的git commit操作中，就不要带文件名了，否则会报错，如下：
git此时还是不知道用哪个分支的hello.txt，所以提交的时候不要带文件名了。
可以看到合并成功，接着查看下文件内容，cat hello.txt，结果如愿以偿。
注意，这里合并时候的修改，也只是改了master分支的文件内容，hot-fix分支是不受影响的，可以切到hot-fix查看文件内容便知。
分支原理
跟版本切换一样，分支切换的底层同样是指针。
上面的2个分支master和hot-fix，其实都是指向具体版本记录的指针。而当前所在的分支，其实是有HEAD决定的，HEAD指向哪个分支，现在就在那个分支上。
所以，创建分支的本质就是多创建一个指针，故切换分支的本质就是移动HEAD指针。
接下来是git的团队协助相关内容。
