GIT学习笔记（3）：分支管理
GIT学习笔记（3）：分支管理
何谓分支
GIT是如何存储数据的
GIT不是存储文件差异或者变化量，而是一系列文件的快照。在Git提交时，会保存一个提交(commit)对象，该对象包含一个指向暂存内容快照的指针，它大概是这样子的。
三个表示文件快照内容的 blob 对象；一个记录着目录树内容及其中各个文件对应 blob 对象索引的 tree 对象；以及一个包含指向 tree 对象（根目录）的索引和其他提交信息元数据的 commit 对象。
多个提交对象之间是链接关系，每个提交对象会指向上一个提交对象，如下图所示：
引入分支
Git 中的分支，其实本质上仅仅是个指向 commit 对象的可变指针。Git 会使用 master 作为分支的默认名字。在若干次提交后，你其实已经有了一个指向最后一次提交对象的 master 分支，它在每次提交的时候都会自动向前移动。
创建一个新分支
创建一个新的分支很简单，比如新建一个testing分支，可以使用命令git branch testing，此时将会有两个分支指向当前commit对象。
那么，Git 是如何知道你当前在哪个分支上工作的呢？其实答案也很简单，它保存着一个名为 HEAD 的特别指针。它是一个指向你正在工作中的本地分支的指针（将 HEAD 想象为当前分支的别名。）。我们创建了新的分支，但是并不会自动切换到这个分支中去，所以我们依然在master分支中进行，我们可以使用git checkout testing命令，来转换到新建的分支中去。
之后每次提交，HEAD将随着分支一起向右移动，如下图所示HEAD跟随testing进行移动。
当然，我们可以使用checkout切换回matser分支，这样再次提交就会产生不同的流向
分支的合并
通过上面内容，我们已经理解了分支的基本概念已经分支的新建切换步骤等等，下面我们来探讨一下分支的合并。
分化分支的合并
如下图所示，hotfix分支是master分支的分化分支，所谓分化，既是源于master，matser是其父级。
hotfix做了一些操作后，比如修复BUG，master认为hotfix修复了其关键故障，想合并hotfix分支，我们可以回到master，然后指向git merge hotfix命令。
此时发现master和hotfix指向了同一个commit对象。由于 master 分支所在的提交对象是要并入的 hotfix 分支的直接上游，Git 只需把 master 分支指针直接右移。换句话说，如果顺着一个分支走下去可以到达另一个分支的话，那么 Git 在合并两者时，只会简单地把指针右移，因为这种单线的历史分支不存在任何需要解决的分歧，所以这种合并过程可以称为快进（Fast forward）。
这个时候，hotfix已经完成了历史使命，可以删掉了，使用git branch -d hotfix可以删除不用的分支。
反思：看到这里我们可以想一下实际的业务场景，比如我们matser版本出现问题，我们可以先创建一个新的分支进行修改，如果修复成功了，master合并即可，即使没有成功，也不会对master有任何影响。
基于共同祖先的合并
比如maste分支r想要合并iss53分支，由于当前 master 分支所指向的提交对象（C4）并不是 iss53 分支的直接祖先，Git 不得不进行一些额外处理。就此例而言，Git 会用两个分支的末端（C4 和 C5）以及它们的共同祖先（C2）进行一次简单的三方合并计算。
即如下图所示：
这次，Git 没有简单地把分支指针右移，而是对三方合并后的结果重新做一个新的快照，并自动创建一个指向它的提交对象（C6）。
既然之前的工作成果已经合并到 master 了，那么 iss53 也就没用了。你可以就此删除它。
遇到冲突时的分支合并
有时候合并操作并不会如此顺利。如果在不同的分支中都修改了同一个文件的同一部分，Git 就无法干净地把两者合到一起，比如我们合并master与tesing分支。
此时会出现问题，因为他检测出来两个分支都对Test.java进行了操作，他对Test.java进行了合并，但没有提交，它会停下来等你解决冲突。打开Test.java文件，我们发现它自动的把两者的内容放在一起，让我们做出选择
我们自行做出修改，然后运行git add将其表示为已经解决状态，最后提交即可。
到这里分支管理的基础内容已经讲完了，关于远程分支等内容我们将在下篇文章中详细说明，谢谢关注！
