目录结构:
.
├── branches
├── config
├── description
├── HEAD
├── hooks
│ ├── applypatch-msg.sample
│ ├── commit-msg.sample
│ ├── post-update.sample
│ ├── pre-applypatch.sample
│ ├── pre-commit.sample
│ ├── prepare-commit-msg.sample
│ ├── pre-push.sample
│ ├── pre-rebase.sample
│ └── update.sample
├── info
│ └── exclude
├── objects
│ ├── info
│ └── pack
└── refs
├── heads
└── tags
9 directories, 13 files
当我们创建一个仓库时,默认情况下会创建工作目录,在工作目录下有个 .git 的子目录,这才是存储库的目录。 而我们通常
修改代码的目录称之为工作目录。
众所周知,git 是分布式版本控制系统,这就意味着,只要获得了 .git 目录的完整数据,就可以在任意位置恢复成一个带有工
作目录的仓库。而 GIT 克隆一个存储库也仅仅是将 .git/objects 目录下的 object 和 .git/refs (.git/packed-refs|.git/info/refs) 所存
储的引用列表传输到本地,并应用。
对于 Subversion 一样的集中式版本控制系统,就相当于 .git 目录被托管在中央服务器上,而本地的 .svn 只是工作目录的元数
据。
二者不同的机制带来的直接差别就是一旦中央服务器宕机,git 可以迅速的迁移到其他服务器,并且数据的丢失的可能性很
小,而 Subversion 服务器就没有这么好的运气了。
每一次提交,git 都会把修改的文件快照,还有更新的目录结构,以及提交信息,打包成一个个 object,这些 object 被loose
object, 所以 git 的 object 可能是 blob tree commit 等。打包的过程会使用 zip 压缩,这种被广泛运用的压缩格式实上压缩率较
低,压缩速度也慢,但好处有广泛的支持,专利上比较友好。
如果调用 git gc 命令后,git-gc 会将这些 object 打包成 pack 文件,这些内容在 proGit 都有详细说明。
Git 传输协议
Git 支持多种协议 http, git , ssh, file ,以内部机制区分为哑协议和智能协议,哑协议非常简单,简单的说, 客户端通过 URL 直
接拿取服务端的文件。