第 3 章 克隆代码库
在较老一代的版本控制系统里，checkout是获取文件的标准操作。你将获得一组特定保 存状态的文件。
在Git和其他分布式版本控制系统里，克隆是标准的操作。通过创建整个仓库的克隆来获得文件。或者说，你实际上把整个中心服务器做了个镜像。凡是主仓库上能做的事， 你都能做。
封闭源码
闭源项目须避免执行touch命令，并确保你从未创建`git-daemon-export-ok`文件。资源 库不再可以通过git协议获取；只有那些有SSH访问权限的人才能看到。如果你所有的资源 库都是封闭的，那也没必要运行运行git守护了，因为所有沟通都走SSH。
裸仓库
之所以叫裸仓库是因为其没有工作目录；它只包含正常情况下隐藏在`.git`子目录下 的文件。换句话说，它维护项目历史，而且从不保存任何给定版本的快照。
裸仓库扮演的角色和中心版本控制系统中中心服务器的角色类似：你项目的中心。开 发从其中克隆项目，捡入新近改动。典型地裸仓库存在一个服务器上，该服务器除了 分散数据外并不担负额外的任务。开发活动发生在克隆的代码库上，因此中心仓库没 有工作目录也行。
很多Git命令在裸仓库上失败，除非指定仓库路径到环境变量`GIT_DIR`，或者指定 `--bare`选项。
推还是拽
为什么我们介绍了push命令，而不是依赖熟悉的pull命令？首先，在裸仓库上pull会 失败：除非你必须“fetch”，一个之后我们要讨论的命令。但即使我们在中心服务器上 保持一个正常的仓库，拽些东西进去仍然很繁琐。我们不得不登陆服务器先，给pull 命令我们要拽自机器的网络地址。防火墙会阻碍，并且首先如果我们没有到服务器的 shell访问怎么办呢？
然而，除了这个案例，我们反对推进仓库，因为当目标有工作目录时，困惑随之而来。
简短来说，学习Git的时候，只在目标是裸仓库的时候使用push，否则用pull的方式。
项目分叉
项目走歪了吗？或者认为你可以做得更好？那么在服务器上：
$ git clone git://main.server/path/to/files
之后告诉每个相关的人你服务器上项目的分支。
在之后的时间，你可以合并来自原先项目的改变，使用命令：
$ git pull
终极备份
需要制作很多散布在各处，并禁止篡改的冗余存档吗? 如果你的项目有很多开发者参 与，那你并不需要再做什么了。每份代码克隆都是一个有效备份。它不仅包含当前代码 库状态，也同时包含了项目的整个历史。多谢哈希加密算法，如果任何人的克隆库被损 坏，只要其与其他克隆库交互，损坏的代码就会被显示出来。
如果你的项目并不是那么流行，那就找尽可能多的伺服来存放克隆库吧。
真正的偏执狂应该总是把HEAD最近20字节的SHA1哈希值写到安全的地方。应该保证安全， 而不是把它藏起来。比如，把它发布到报纸上就不错，因为对攻击者而言，更改每份报 纸是很难的。
轻快多任务
比如你想并行开发多个功能。那么提交你的项目并运行：
$ git clone . /some/new/directory
Git使用硬链接和文件共享来尽可能安全地创建克隆，因此它一眨眼就完成了，因此你现 在可以并行操作两个没有相互依赖的功能。例如，你可以编辑一个克隆，同时编译另一 个。感谢 hardlinking, 本地克隆比简单 备份省时省地。
现在你可以同时工作在两个彼此独立的特性上。比如，你可以在编译一个克隆的时候编 辑另一个克隆。任何时候，你都可以从其它克隆提交并拖拽变更。
$ git pull /the/other/clone HEAD
Mercurial
Mercurial是一个类似的的版本控制系统，几乎可以和Git一起无缝工作。使用 `hg-git`插件，一个Mercurial用户可以无损地往Git仓库推送，从Git仓库拖拽。
使用Git获得`hg-git`插件：
$ git clone git://github.com/schacon/hg-git.git
或使用Mercurial:
$ hg clone http://bitbucket.org/durin42/hg-git/
不好意思，我没注意Git有类似的插件。因此, 我主张使用Git而不是Mercurial作为主资 源库，即使你偏爱Mercurial。使用Mercurial项目，通常一个自愿者维护一个平行的 Git项目以适应Git用户，然而感谢`hg-git`插件，一个Git项目自动地适应Mercurial用 户。
尽管该插件可以把一个Mercurial仓库转成一个Git仓库，通过推送一个空仓库来实现， 这个差事交给`hg-fast-export.sh`脚本来做还是更容易些。这个脚本来自：
$ git clone git://repo.or.cz/fast-export.git
如需转化，只需在一个空目录运行：
$ git init $ hg-fast-export.sh -r /hg/repo
注意，需要先将该脚本加入你的`$PATH`路径中，再执行以上命令行。
Bazaar
我们简略提一下Bazaar，它毕竟是紧跟Git和Mercurial之后最流行的自由分布式版本控 制系统。
Bazaar有后来者的优势，它相对年轻些；它的设计者可以从前人的错误中学习，并且避免 先行者在历史上犯过的错误。另外，它的开发人员对可移植性以及和与其它版本控制系统 的互操作性也考虑周全。
一个`bzr-git`插件让Bazaar用户在一定程度下可以工作在Git仓库。`tailor`程序转 换Bazaar仓库到Git仓库，并且可以递增的方式做，要知道`bzr-fast-export`只是 在一次性转换性情况下工作良好。
我偏爱Git的原因
我起先选择Git是因为我听说它能管理不可想象地不可管理的Linux内核源码。我从来没 觉得有离开的必要。Git已经工作的很好了，并且我也没有被其瑕疵所困扰。因为我主要 使用Linux，其他平台上的问题与我无关。
还有，我偏爱C程序和bash脚本，以及诸如Python的可执行可脚本：其代码依赖性较低，并 且我也沉迷于快速的执行时间。
我考虑过Git如何才能提高，甚至自己写过类似的工具，但只作为学术研究练练手。即使我 会完成这个项目，我也无论如何会继续使用Git，因为使用一个古里古怪的系统所获甚微。
自然地，你的需求和期望可能不同，并且你可能感觉使用另一个系统会好些。即便如此，使 用Git你都不至于错太远。