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不仅一开始提供了功能齐全的底层命令,而且还提供了许多友好的高层命令。
Procelain(高层命令)
user-friendly commands: init, add, commit, push, checkout, branch, merge, etc.
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。
而集中式版本控制系统的缺点,则有如下几点:
对于集中式版本控制系统,在多人协作中,可以认为如果commit越早,麻 烦也就越少。
从这个角度上看,可以认为git做了两步commit操作,第一次为commit,第二次为pull,只有pull才需要re-sync。
在没有commit之前所有文件都在于client端的本地文件,如果此时不小心删除掉了一些文件,除非重新访问server进行回滚操作,否则就真的删除掉
当server没有备份并且宕掉了,就算能恢复当前版本的数据,但是之前的历史数据信息是恢复不了的。
大部分时间都是需要client和server进行沟通协作的。
2.2 分布式版本控制系统
我们再来看看git,它是一个分布式版本控制系统。
与传统的集中式版本控制系统相比,git最大的不同在于,它是分布式版本控制系统。分布式意味着,不止服务器保存有version database,每个客户端也保存有version database。git的主要特点如下:
每次clone都真正的拷贝所有的数据。
在初始clone之后,大多数的操作都是在本地进行的。
而git版本控制系统的主要优点如下三点:
除了第一次clone的时候慢,之后的操作都比较快。因为大多数操作都是在本地进行的,不需要联网。
你可以对本地的version database做任何你想做的事情,他并不会对其他人 造成任何影响。
在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到底是什么?
1. 本质上,是一套内容寻址文件系统(Content Addressable Filesystem)。
2. 实现上,是一个简单的KV数据库
3. 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操作。它的操作流程和示意图如下:
这步操作的速度很快。因为只需要去比较文件的hash值是否匹配即可。
这步操作并不会覆盖分支里之前的版本数据。
当merge操作完成后,示意图如下:
首先,可以发现,这是会新建一个mater处的commit object,而它有两个parent指针,分别指向之前两个branch的commit object。
其次,如果不小心做了一个bad merge,而又不想让他人知道时,其实只需要更改下master和feature指针的hash信息即可。
最后,通过branch和merge操作,你会发现在git的世界里,它会尽量不让你做删除的事情。
5、 小结
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本质上仍然是一个文件系统,只是它很适合地被用作版本控制系统。