要理解 Git 的工作方式，首要大事就是明白它的版本控制方式与 Subversion（SVN）、Perforce 或者其他任何你用过的源码管理工具都是不同的。通常，把原先的理解全部忘掉，反而更容易了解 Git。

让我们从头开始。假设你正要设计一个源码管理系统。在你使用一个版本控制工具之前，是怎么完成最基本的版本控制工作的呢？很有可能想下边这样，把你的项目文件夹作一份拷贝：

$ cp -R project project.bak

这样，如果接下去对 project 做了坏事，还有备胎（project.bak）可以救火；或者看看最新的项目和作拷贝时的项目的对比，看看做了哪些改动。

如果你是个偏执狂，那么你可能经常这样做，为每个备胎加一个时间戳：

$ cp -R project project.2010-06-01.bak

这样，你就有了一堆项目备胎可以随时查看、比较。你还可以以此模式有效地与人分享项目的改动。如果你给到了一定阶段的项目打个包，丢到网站上，别的开发人员就能下载到它，并把改动的地方打个补丁，发送给你。

$ wget http://sample.com/project.2010-06-01.zip
$ unzip project.2010-06-01.zip
$ cp -R project.2010-06-01 project-my-copy
$ cd project-my-copy
$ (change something)
$ diff project-my-copy project.2010-06-01 > change.patch
$ (email change.patch)

现在项目原来的开发者就能收到，并将补丁打到项目里头去了。许多开源项目都曾以这种模式进行过多年时间。

事实上，这模式挺好用，现在我们要做的工作是，把这个模式流程化，弄个工具，让它更快、更容易。与其像 Subversion 那样记录每个文件的版本，我们更乐意有个工具能够不用通过复制文件夹来存储整个项目的快照。

这就是 Git 的关键所在。通过命令 git commit 告诉 Git 记录一下当前的项目快照。而 Git 就会记下当前项目的结构、文件。

所以，只要你把 Git 看成为你的项目提供记录快照，并对这些快照做比较、合并、删除等操作的工具，就能为日后使用打开方便理解之门了。

---

翻译自 gitref.org，不知道是否有人做过这工作。