分布式存储 Git 的核心概念(4)

在.git\refs\heads文件夹下新建一个文件名为dev（没有扩展名）的文本文件。

将HEAD指向的当前分支（当前为master）的40位SHA-1 校验和外加一个换行符写入dev文件。

结束。

创建分支就是这么简单，那么切换分支呢？更简单：

修改.git文件下的HEAD文件为ref: refs/heads/<分支名称>。

按照分支指向的提交记录将工作区的文件恢复至一模一样。

结束。

记住，HEAD文件指向当前分支的最后一次提交，同时，它也是以当前分支再次创建一个分支时，将要写入的内容。

再来说一说合并，首先是Fast-forward，换句话说，如果顺着一个分支走下去可以到达另一个分支的话，那么 Git 在合并两者时，只会简单地把指针右移，因为这种单线的历史分支不存在任何需要解决的分歧，所以这种合并过程可以称为快进（Fast forward）。比如：

注意箭头方向，因为每一次提交都有一个指向上一次提交的指针，所以箭头方向向左，更为合理

当在master分支合并dev分支时，因为他们在一条线上，这种单线的历史分支不存在任何需要解决的分歧，所以只需要master分支指向dev分支即可，所以非常快。

当分支出现分叉时，就有可能出现冲突，而这时Git就会要求你去解决冲突，比如像下面的历史：

因为master分支和dev分支不在一条线上，即v7不是v5的直接祖先，Git 不得不进行一些额外处理。就此例而言，Git 会用两个分支的末端（v7和v5）以及它们的共同祖先（v3）进行一次简单的三方合并计算。合并之后会生成一个和并提交v8：

注意：和并提交有两个祖先（v7和v5）。

把一个分支中的修改整合到另一个分支的办法有两种：merge和rebase。首先merge和rebase最终的结果是一样的，但rebase能产生一个更为整洁的提交历史。仍然以上图为例，如果简单的merge，会生成一个提交对象v8，现在我们尝试使用变基合并分支，切换到dev：

$ git checkout dev
$ git rebase master
First, rewinding head to replay your work on top of it...
Applying: added staged command

这段代码的意思是：回到两个分支最近的共同祖先v3，根据当前分支（也就是要进行变基的分支dev）后续的历次提交对象（包括v4，v5），生成一系列文件补丁，然后以基底分支（也就是主干分支master）最后一个提交对象（v7）为新的出发点，逐个应用之前准备好的补丁文件，最后会生成两个新的合并提交对象（v4'，v5'）,从而改写dev的提交历史，使它成为 master 分支的直接下游，如下图：

现在，就可以回到master分支进行快速合并Fast-forward了，因为master分支和dev分支在一条线上：

$ git checkout master
$ git merge dev

现在的v5'对应的快照，其实和普通的三方合并，即上个例子中的v8对应的快照内容一模一样。虽然最后整合得到的结果没有任何区别，但变基能产生一个更为整洁的提交历史。如果视察一个变基过的分支的历史记录，看起来会更清楚：仿佛所有修改都是在一根线上先后进行的，尽管实际上它们原本是同时并行发生的。

1、Git保存文件的完整内容，不保存差量变化。

2、Git以储键值对（key-value）的方式保存文件。

3、每一个文件，相同文件的不同版本，都有一个唯一的40位的 SHA-1 校验和与之对应。

4、SHA-1 校验和是文件的指针，Git依靠它来区分文件。

5、每一个文件都会在Git的版本库里生成blob对象来保存。

6、对于没有变化的文件，Git只会保留上一个版本的指针。分布式存储

7、Git实际上是通过维持复杂的文件树来实现版本控制的。

8、使用Git的工作流程基本就是就是文件在三个工作区域之间的流动。

9、应该大量使用分支进行团队协作。

10、分支只是对提交对象的一个引用。

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-63562-4.html