分支原理
git把我们之前每次提交的版本串成一条时间线，这条时间线就是一条分支。在git里，这个分支就是主分支，即master分支。HEAD严格来说不是指向提交，而是指向master。master才是指向提交的版本，所以，HEAD指向的就是当前分支。
每次提交，master分支都会向前移动一步。这样，随着不断提交，master分支的线也越来越长。
当我们创建新的分支dev，git创建了一个指针叫dev。指向master相同的提交。再把HEAD指向dev，就表示当前分支在dev上。
git创建一个分支很快，因为除了增加一个dev指针，改变HEAD的指向，工作区的文件没有任何变化。
假如我们在dev上的工作完成了，就可以把dev合并到master上。怎么合并的呢？git直接把master指向dev的当前提交，就完成了合并。
合并分支也很快，就改改指针。工作区的内容不变。
合并完分支后，甚至可以删除dev分支，删除dev分支就是把dev指针给删掉。删掉后，我们只剩下一条master指针。
分支作用
分支在实际中有很大用处。假设你准备开发一个新功能，但是需要两周才能完成，第一周只写了一半的代码。如果立刻提交，由于代码还没写完，不完整的代码库会导致别人无法干活，如果等代码全部写完，又存在丢失每天进度的巨大风险。有了分支，就不用怕这些事情。你创建自己的一个分支，别人看不到，也可以在原来的分支上工作。而你还在自己的分支上干活，想提交就提交。直到全部开发完，一次性合并到主分支。这样既安全，又不影响别人工作。
分支基本操作
查看当前几个分支且能看到在哪个分支工作
git branch
创建分支
git branch 分支名
创建分支并切换到其上工作
git checkout -b dev
切换回master分支
git checkoout master
合并分支
git merge 分支名字
注意上面的Fast-forward，也就是红色框。git告诉我们，这次合并是快速合并，也就是直接把master指向dev的当前提交，所以合并速度非常快
解决冲突
合并冲突并不是一番风顺的。在两个分支上修改同一个文件并提交，就会起冲突。解决办法：手动解决冲突，再提交一次
看下图：
git告诉我们，git_test2.txt文件存在冲突，必须手动解决冲突再提交。
打开刚才修改的文件，发现文件修改了
将文件中新增加的<、= 和 >手动删掉，再提交一次
删除分支
git branch -d 分支名字
这个操作也是非常快的，直接把dev这个指针删了就好了。
分支管理策略
通常，合并分支时，如果可能，git会用fast forward模式。但是有些快速合并并不能合并但不会起冲突，合并之后并做一次新的提交。在这种模式下，删除分支后，会丢掉部分信息。
如上图，merge并不会起冲突(因为不是同一个文件)。但是，会出来一个框：
为什么会出现这个框？前面我们说了，合并分支无法合并但不会起冲突且做一次提交。在这次提交中，需要输入描述信息。就在弹窗输入描述信息
PS：我太难了，我接下来一直退不出这个框。所以这个例子就这样吧。可以的跟我说一下，拜托了。
禁用快速合并：
git merge —no-ff -m “描述” 分支名
Bug分支
软件开发中，bug就像家常便饭，有了bug就要修复。在git中，由于分支是如此强大，所以，每个bug都可以通过一个新的临时分支来修复。修复后，合并分支，然后将临时分支删除。这个例子不难，就不贴图了。
假如你正在写代码，突然老大让你修改一个bug。你需要先保存一下工作现场，修复完bug后，再恢复工作现场。
