【第三章】Git 分支（上）

真正使得Git从版本控制家族中分离出来的正是Git的分支模型，那么下面将介绍到底Git在这个方面做了哪些特别之处

一、分支

Git每次提交都是提交了新的文件内容，以及一个包含本次提交有哪些文件的“tree”，这个“tree”中包含了这次提交包含了那些文件的指针。

在提交完成后，这次的提交对象会再包含上一个指向上次提交对象的指针（parent指针）

所谓的分支，就是一个指向commit对象的可变指针，Git默认使用master作为分支的名字，每一次提交新的commit后，master指针都会向前移动。

git branch testing 创建新的分支testing

同时，Git还会保存一个特别的HEAD指针，这个指针指向了你正在工作中的本地分支的指针，刚刚我们创建了一个testing的分支，但是由于只是创建，并没有切换到该分支上，所以HEAD指针是指向master的

如果要切换到新的分支，使用checkout命令
git checkout testing

这个时候再提交一次commit时，就会发现变成了这样

当我们切换回master分支：git checkout master
再重新做一次新提交之后，会变成这样：

如此，Git对于版本的控制与其他的版本控制系统就有了很大的差别，其他的系统管理分支大多采取备份所有的项目文件到一个指定的目录中，由于采取的是备份的方式，所以当项目复杂度上升时，所用的时间也变长。而Git可以在几毫秒的时间里完成分支的创建与切换。同时，由于Git记录了祖先信息，所以在进行分支合并时，也会非常容易寻找到合并基础。

二、分支的新建与合并

假设现在有这样的一个项目，它已经推进到了C2阶段，此时C2阶段是已经上线的项目，是稳定的。

当我们需要在此基础上开发一个新的功能，就需要新建一个分支，在新的分支上进行开发
git checkout -b iss53

此时我们做一个新的提交：

然而突然有人跟你说原来的C2版本出现了一个很严重的问题，需要马上修改，此时我们需要停下iss53的开发任务，回到master分支上，重新新建一个hotfix分支来进行紧急修改：
git checkout master
git checkout -b hotfix
vim xxx
git commit -a -m ‘xxxx’
**注意：**在转换到master分支时，要保持一个清洁的工作区域（stashing或commit amending，之后会介绍如何使用），否则将会检测出冲突

在对C4完成测试之后，回到master分支，将master与hotfix合并起来：
git checkout master
git merge hotfix
由于master在hotfix的直接上游，所以此时的合并操作只是简单地将master指针右移，这种合并过程被称为“快进（fast forward）”

此时hotfix完成了自己的使命，可以删掉，并回到iss53的开发中并做新的提交：
git branch -d hotfix
git checkout iss53

好，现在iss53的问题也修改完成，需要将其跟master分支进行合并：
git checkout master
git merge iss53
要注意的是，这一次的合并中，master并不是iss53的直接上游，所以Git会用这两个分支的末端（C4和C5）以及他们共同祖先C2进行一次简单的三方合并计算

Git对三方合并后的结果重新做一个新的快照，并自动创建一个指向它的提交对象C6，这个对象的祖先有两个（C4和C5）

在分支合并这一点上，Git不同于其他的版本控制系统，其他的版本控制系统都需要手动来指定合并的基础，而Git可以自己裁决哪个共同的祖先才是最佳的合并点

最后，删除iss53：
git branch -d iss53

三、遇到冲突时的合并

合并过程往往并不那么顺利，当Git合并产生冲突时，它会停下来等待冲突的解决，此时Git做了合并操作，但是并没有进行提交，它在等待冲突的解决。查看冲突的方式用git status查阅：

包含冲突的文件都以unmerge的状态列出，Git会在有冲突的文件中加入标准的冲突解决标记，可以手工定位这些标记来解决冲突：

最后修改完成，如下：

在解决完冲突之后，需要运行git add来将这些未保存的文件放到暂存区。如果想要用一个有图形界面的工具来解决这些问题，可以运行git mergetool，默认设置了opendiff工具
最后，使用git commit来完成这次的合并的提交