git分治之道
git内部原理
1.什么是git
git的官方定义：
Git is a fast, scalable, distributed revision control system with an unusually rich command set that provides both high-level operations and full access to internals.
可以看出，git是一个具有丰富命令集的版本控制系统，它的特点就是快速、可扩展以及分布式。
而git实际上是一个简单内容记录工具（the stupid content tracker）。从根本上来讲，git 是一套内容寻址 (content-addressable) 文件系统，在此之上提供了一个版本控制系统的用户界面。
1.1 an unusually rich command set
在当前版本里，git一共有158个命令，但是常用命令只有10多个，其他命令可以视为底层命令。由于git最开始被设计的时候用来作为the stupid content tracker，只是现在被最广泛地用来作为revision control system，但是实际上git也可以被用来做其它事情。因此，git不仅一开始提供了功能齐全的底层命令，而且还提供了许多友好的高层命令。
git命令分为两种：
1. Procelain（高层命令）
user-friendly commands: init, add, commit, push, checkout, branch, merge, etc.
2. Plmbing（底层命令）
bunch of verbs that do low-level work: hash-object, update-index, write-tree, etc.
1.2 revision control system
版本控制系统，学名：software change and configuration management system(SCM)。它需要具有的特点如下：
记录和控制软件的变化点和版本号
能清楚知道什么东西被改了，被谁改了
在多人完成的大项目中，能更加容易的合作和管理文件
最重要的是，要有回滚功能
在实际生活中，版本控制就被经常用到，例如写论文时的版本控制。但是，这只是简单的本地版本控制。在多人的项目合作中，这就显得力不从心了。因为使用这种方法时，首先需要大量的拷贝工作，以保证能够回滚嘛；其次当多人更改同一项目出现写写冲突情况时，虽然Linux提供diff和patch命令，但是解决起来肯定极其痛苦。
因此，版本控制系统，核心就是让在不同系统上的开发者协同工作，需要解决的主要问题就是防止各种人一块写最后写乱套的情况。
2. git有何不同
2.1 集中式版本控制系统
首先，谈谈传统的集中式版本控制系统。
集中式版本控制系统中，版本库是集中存放在中央服务器(server)，每个开发者都作为客户端(client)。协同工作的开发者都通过客户端连到中央服务器，取出(checkout)最新的文件或者提交(commit)更新。它的主要特点如下：
每次checkout拿到的都是当前版本库最新的一个快照状态(snapshot)。它并不知道版本库之前的历史状态信息。
每次commit都会更新中央版本库。
为了保证不丢失数据，在每次commit时都需要re-sync。
而集中式版本控制系统的缺点，则有如下几点：
1. 对于每次commit操作，都需要re-sync；
对于集中式版本控制系统，在多人协作中，可以认为如果commit越早，麻烦也就越少。
从这个角度上看，可以认为git做了两步commit操作，第一次为commit，第二次为pull，只有pull才需要re-sync
2. 单点故障；
在没有commit之前所有文件都在于client端的本地文件，如果此时不小心删除掉了一些文件，除非重新访问server进行回滚操作，否则就真的删除掉了。
当server没有备份并且宕掉了，就算能恢复当前版本的数据，但是之前的历史数据信息是恢复不了的。
3. 每次工作的时候，需要联网；
4. 速度慢；
大部分时间都是需要client和server进行沟通协作的。2.2 分布式版本控制系统
我们再来看看git，它是一个分布式版本控制系统。
与传统的集中式版本控制系统相比，git最大的不同在于，它是分布式版本控制系统。分布式意味着，不止服务器保存有version database，每个客户端也保存有version database。git的主要特点如下：
每次clone都真正的拷贝所有的数据。
在初始clone之后，大多数的操作都是在本地进行的。
而git版本控制系统的主要优点如下三点：
1. Fast：
除了第一次clone的时候慢，之后的操作都比较快。因为大多数操作都是在本地进行的，不需要联网。
2. Scalable：
你可以对本地的version database做任何你想做的事情，他并不会对其他人造成任何影响。
3. Distributed：
在client端，肯定不法彻底避免单点故障，但是可以减少这样可能性。因为本地保存有version database，所以当本地不小心丢失文件时，往往可以本地出错本地解决。
在server坏掉的时候，可以根据client里面的version database进行恢复，甚至可以把client当成一个新的server。
3. git如何存储内部数据
从上一小节，我们知道git是一个分布式版本控制系统，无论是服务端还是客户端都拥护一份自己的version database。那么本小节，首先看看version database到底是什么。然后，分别深入看看git init、git add、git commit这个三个常用命令具体的工作过程。
version database
git的version database到底是什么？
本质上，是一套内容寻址文件系统（Content Addressable Filesystem）。
实现上，是一个简单的KV数据库
Key: sha-1 hash(everything is hashed)
20 bytes, 40 hex, 160 bit, 2.9e48 distinct keys
- How would git handle a SHA-1 collision on a blob?
4. Value: binary files
Commits : actual git commits
Trees : directories(structure of file system)
Blobs : contents of files/data
git以一种类似UNIX文件系统但更简单的key-value方式来存储内容。key是对文件内容的哈希值。value则包含有commit object、tree object以及blob object三种对象。
所有内容以tree或blob对象存储，其中tree对象对应于UNIX中的目录，blob对象则大致对应于inodes或文件内容。commit对象则可以看作是对当前版本的一个快照。
一个单独的tree对象包含一条或多条tree记录，每一条记录含有一个指向blob或子tree对象的SHA-1指针，并附有该对象的权限模式、类型和文件名信息。
接下来一步一步，看来git flow里到底发生了什么：
3.1 git init命令
git init主要是创建了四个文件夹：.git、.git/refs/heads、.git/refs/tags以及.git/objects，和一个文件.git/HEAD，并把初始化./git/HEAD里面的内容为指向master branch的HEAD。
那么如何用普通的Linux命令实现git init呢？答案其实很简单：
mkdir .git
mkdir -p .git/refs/heads
mkdir -p .git/refs/tags
mkdir -p .git/objects
touch .git/HEAD
echo "ref:refs/heads/master" > .git/HEAD
以上便是git init, without git init的具体实现做法。其中，objects目录存储所有数据内容，refs目录存储指向数据(分支)的提交对象的指针，HEAD文件指向当前分支。
3.2 git add命令
git add做了两件事情：第一，把文件写成blob object作为value，并把文件内容的hash值作为key；第二，更新了index文件，把文件放入了暂存区（staging area）。
echo "Hello World" > hello.txt
git add .
上面的操作可以用下面底层语句实现：
echo "Hello World" | git hash-object -w --stdin
git update-index --add --cacheinfo 100644 557db03de997c86a4028e1ebd3a1ceb225be238 hello.txt
git checkout -- hello.txt
第一个命令中，参数-w指示hash-object命令存储(数据)对象，若不指定这个参数该命令仅仅返回键值。该命令输出长度为40个字符的SHA-1哈希值校验和，并创建以它的前2个字符为名称的子目录，剩下38个字符作为文件命名(保存至子目录下)。
第二个命令，update-index为一个单独文件创建一个index。更新完staging area后，由于仅仅Index里有，但是本地仍没有，如果git status，所以会显示为deleted。此时，使用第三条命令可以把repository进行checkout出来。
3.3 git commit命令
我们进行第一次git commit操作。
git commit -m "First Commit"
此时会多出两个文件。
第一个是commit object，它实际上是对于跟踪项目内容的一次快照，里面的格式内容有：指明了该时间点项目快照的顶层树对象、作者/提交者信息以及提交注释信息；
第二个则是那个被指向tree object，它实际上一个文件根目录，里面指向一个blob object，而这个blob object便是之前git add时的内容。
虽然执行git log命令可以查看完整的历史信息并以此找到文件，那么问题来了，系统又是如何找到commit log的呢？ 答案是：refs!
在.git/HEAD里存的是一个ref，ref是一个file，这个file里面又存了一个commit的hash值，从而便可以找到了当前的base版本。
我们尝试进行第二次git commit操作。 首先，git add一个简单的脚本文件hello.sh。
/*************hello.sh的具体内容如下：
!/bin/sh
echo "Hello World"
**************/
git add hello.sh
此时，git add只会增加一个blob object，而不会增加多一个tree object。也就是说，在add的时候并不写目录，只是更新了暂存区，在index里会保存目录信息。因为在git commit操作前，可以进行多次git add操作。
git commit -m "Second Commit"
此时，会多出三个文件。第一个是commit object，第二个是根目录的tree object，第三个是文件目录的tree object。
通过下图，可以发现commit object中还带有个parent指针，它指向上一次的commit object。最重要的是，它还更新自身的refs/heads/master信息；
通过命令git ls-files --stage查看staging area信息。你还可以发现，暂存区里只存储blob object，并不存储tree object和commit object。
4. branch/merge在git内部是如何工作
相对于git init、git add、git commit这三个命令，git branch和git merge则显得十分的小巧机智。结合下列几幅图，能更轻松的理解这两个命令。
4.1 branch操作
在git里，branch操作，实际上仅仅增添一个41-bytes的引用文件(在refs/heads/目录底下)。可以看出，这样的操作是极其的简单廉价的，示意图如下：
同理，在git里，checkout操作，实际上也仅仅是更改了引用文件的指针而已。
4.2 merge操作
最后，我们来分析一下，git里的merge操作。它的操作流程和示意图如下：
计算出当前branch和公共branch的diff；
这步操作的速度很快。因为只需要去比较文件的hash值是否匹配即可。
2. 应用该diff去订正本地文件；
这步操作并不会覆盖分支里之前的版本数据。
3. 解决所有的冲突；
当merge操作完成后，示意图如下：
首先，可以发现，这是会新建一个mater处的commit object，而它有两个parent指针，分别指向之前两个branch的commit object。
其次，如果不小心做了一个bad merge，而又不想让他人知道时，其实只需要更改下master和feature指针的hash信息即可。
最后，通过branch和merge操作，你会发现在git的世界里，它会尽量不让你做删除的事情。
小结
Git is the stupid content tracker.
You can represent renames on top of git - git itself really doesn't care. In many ways you can just see git as a filesystem - it's content-addressable, and it has a notion of versioning, but I really really designed it coming at the problem from the viewpoint of a _filesystem_person (hey, kernels is what I do), and I actually have absolutely _zero_interest in creating a traditional SCM system. -- by Linus Torvalds
我们应该如何看待并理解git呢？本质上，git是一套文件寻址系统。
虽然git具有版本控制的功能，但是在Linus最初设计git的时候，完完全全是从一个文件系统的角度进行设计和实现这个产品的。所以说，git本质上仍然是一个文件系统，只是它很适合地被用作版本控制系统。
本文作者：Junnan Liu，更多内容，请访问：BitTiger.io， 扫描下面二维码，关注微信公众账号“论码农的自我修养”