http://eagain.net/articles/git-for-computer-scientists/
git object storage仅仅是一个DAG of objects, 有几种类型的对象。他们都被压缩保存并以SHA-1 hash来标示。
blob:最简单的对象，仅仅是一堆字节的堆砌。常常它就是一个文件，但是也可以是一个符号链接或者任何其他的东西。指向该blob的对象来指定这个blob的具体语义。
tree: 目录由tree object来标示。他们引用相关的包含文件内容的blobs以及指向其他子目录的trees;
当一个node在DAG中指向另外一个node时，它将依赖于被指向的node： 也就是说这个node不可能在没有被指向的node情况下存在。无任何其他node指向它的node将被git gc命令回收空间，或者类似文件系统无文件名指向的inodes紧急救援命令一样来恢复：git fsck –lost-found
commit:一个commit引用到一个反映在commit执行时文件集状态的tree对象。它也引用0..n个作为它的父辈的commits。多于一个父亲commit则意味着这是一个merge commit,没有parent的commit意味着是initial commit,当然也有可能有不止一个initial commit的情况：这通常意味着两个独立的项目merge到一起了。commit对象的内容是commit 消息。
refs: Referrences,或者heads或者branches就像便签笔记一样提仔DAG里面的一个node上。不像DAG的特性只允许向里面添加node而不允许变更修改，这个便签笔记是可以任意移动的。他们并不在历史中记录，他们并不直接在repo之间传递，他们就像bookmark一样，告示着“i am working here”.
git commit命令将向DAG中添加一个节点并且将当前branch的那个便签向前移动到这个新的node。
HEAD ref有其特别之处，因为它实际上指向另外一个ref.它通常指向当前活动的branch.常见的refs实际上在heads/xxx的namespace,但是你往往忽略heads/这个part
remote refs: Remote referrence被用另外一种颜色来标示出来，它也是一种便签。和normal refs的区别之处是different namespace，而事实是remote refs通常是由remote server来控制，git fetch操作时将会更新它们。
tag:一个tag不仅是DAG中的一个node并且也是一个便签。一个tag指向一个commit，并且包含一个可选的消息和一个GPG signature;
便签本身仅仅提供了一个快速访问tag的方法，一旦被丢失了，也可以通过git fsck –lost-found来找回；
在DAG中的节点可以从一个repo移动到另外一个repo,可以以更加高效的方式来保存（packs)，并且不再使用的nodes将会被垃圾清理。
但是最后，一个git repo总是一个DAG以及对应的便签集合
History:
在有了上面关于git如何保存版本历史的知识后，我们如何能够将类似merges的动作可视化呢？最好用图形来表达：
上面是最简单的一个repo，我们clone了一个remote repo，而该repo只有一个commit在里面；
上面我们已经fetch了remote，该fetch包含了一个其他人的一个commit，而该commit还没有merge；
上图展示了在执行git merge remotes/myserver/master之后的情形。由于merge本事是fast forward(也就是说，我们在local branch上海没有任何新的变更，所以可以直接fast forward)，在merge之后，仅仅的变更时：我们移动了我们的便签到新的node上去，并且相应地变更了working directory的内容；
上图中，我们本地有了一个commit并且做了一个git fetch动作，我们不断本地有一个新的commit而且也有了一个新的remote commit,在这种情况下一个merge是必须的。
git merge remotes/myserver/master执行的结果如上图。由于我们有新的local commits，这时就不再是fast forward,而必须通过在DAG中创建一个新的commit node来指示这个merge.这时注意merge commit有两个parent commits.
在上图中，我们做了几个新的commits并且有了新的merge。git DAG记录了任何已经发生过的action历史；
上面的”缝合“模式有时看起来很让人生烦。如果你还没有publish your branch，或者have clearly communicated that others should not base their work on it,你还有另外一个选项：你可以rebase你的branch，而不是merge.这样做的好处是：你的commit将由另外一个有不同parent的commit来替代，而你的branch将移动到那里。（这个commit将以remote branch的最新commit为parent commit)
你的老的commit将仍然保存在DAG中知道git的垃圾回收机制起作用删除它。当然，如果你有额外的便签指向老的commit，他们将永远指向它，并且正因为有人指向那个不用的commit，这样将使得这个旧的commit得以保存而不被垃圾清理掉。
不要rebase branches that others have created new commits on top of.
在垃圾回收后的情况如上图（或者仅仅或略unreachable commit)，并且在rebased branch上创建一个新的commit
rebase也知道如何在一个commit中来rebase多个commits
