Git 分支管理 - MyBatis中文官网

声明：文中的图片来自于互联网，版权归原作者所有，但文中的文字属于本站原创。

1、Git的存储机制

Git保存的不是文件差异或者变化量，而只是一系列文件快照。也就是说，Git每次修改之后都是整个文件去保存。

有些版本管理工具只是保存每个版本之间的变化，虽然总文件体积小，但是每检出一个文件都要从最开始的版本一个个叠加上去，速度很慢。Git的优势是快，天下武功唯快不破，所以Git最终能一统江湖，千秋万代。

虽然Git的速度很快，但是随着版本的增多或者对于文件特别大的项目，Git会有点吃力。毕竟，存储了过多的文件快照，如同吸星大法一样，会有反噬作用。

因为存在一系列的文件快照节点，从视觉的角度来看，如同串联起来的一个链表，这个系列称之为“分支”。

如下所示，提交了三次，分别是： B0、B1和B2，这三个文件快照的串联被称为“master分支”。

从任意节点可以延伸出一个分支，Git里面的分支很多，但是用户只能操作一个分支，HEAD指向的是当前正在操作的分支，如上图所示。其实，对于 HEAD 的理解还是有一定难度的，特意新写一篇文章专门介绍 HEAD，大家可以移步：《Git HEAD 是什么？》，

备注：在Git中，用户只能操作一个分支，如同用户只能进入某一个目录下操作Linux命令，而不能同时在多个目录下执行命令。

分支是文件快照的串联，同一个文件快照串可以“羽化”出多个分支，如下所示，新建一个dev分支：

当你切换分支的时候，Git 会用该分支的最后提交的快照替换你的工作目录的内容，所以多个分支不需要多个目录。

分支切换命令为：

git checkout branchname

注意：切换分支之后，HEAD也会发生改变，因为HEAD通常会指向当前所在分支。

随着dev分支的不断成长，dev分支与master分支是越来越远，

此时可以合并分支，把dev分支合并到master分支

合并有的时候会出现冲突，如下所示：

在 master 分支和 dev 分支的公共祖先 B2 后，master 和 dev 的提交是对同一个文件的同一个部分进行了不同的修改，Git 就没法合并它们，此时需要手动解决冲突。合并完成之后，产生新的文件快照 B5。

冲突的格式是这样的：

<<<<<<< HEAD
test master.
=======
test dev.
>>>>>>> dev

冲突是通过=======来分割的，其上部分表示HEAD分支的内容，其下部分表示dev分支的内容，这两部分内容发生了冲突。为了解决冲突，你必须选择使用由 ======= 分割的两部分中的一个或者也可以自行合并这些内容。

备注：通过上文Git的HEAD介绍，我们知道，HEAD指向的是当前正在操作的分支。因为运行合并命令（merge 命令）在 master 分支，所以 HEAD 指的是 master分支。

关于冲突合并的更多介绍，请参考下文：