与其一头扎进Git命令的海洋中，不如来点基本的例子试试手。它们简单而且实用。实际 上，在开始使用Git的头几个月，我所用的从来没超出本章介绍的内容。
要不来点猛的？在做之前，先为当前目录所有文件做个快照，使用：
$ git init $ git add . $ git commit -m "My first backup"现在如果你的编辑乱了套，恢复之前的版本：
$ git reset --hard再次保存状态：
$ git commit -a -m "Another backup"以上命令将只跟踪你第一次运行 git add 命令时就已经存在的文件。如果要添加新文...
我将用类比方式来介绍版本控制的概念。更严谨的解释参见 维基百科版本修订控制条目。
我从小就玩电脑游戏。相反，我只是在长大后才开始使用版本控制系统。我想我并不特 殊，并且，对比两者工作方式可使这些概念更易解释，也易于理解。
编写代码，或编辑文档和玩游戏差不多。在你做出了很多进展之后，你最好保存一下。 去做这个，会点击你所信任的编辑器保存按钮就好了。
但这将覆盖老版本。就像那些学校里玩的老游戏，只有一个存档：你确实可以保存，但 你不能回到更老的状态了。这真让人扫兴，因为那个状态可能恰好保存了这个游戏特别 有意思一关，说不定哪天你想再玩一下呢。或者更糟糕的，你当前的保存是个必败局， 这样你就不得不从头开始玩了。
在编辑的时候，如果想保留旧版本，你可以将文件“另存为”一个不同的文件，或在保 存之前将文件拷贝到别处。你可能压缩这些文件以节省空间。这是一个初级的靠手工的 版本控制方式。游戏软件早就提高了这块，很多都提供多个基于时间戳的自动存档槽。
让我们看看稍稍复杂的情况。比如你有很多放在一起的文件，比如项目源码，或网站文 件。现在如你想保留旧版本，你不得不把整个目录存档。手工保存多个版本很不方便， 而且很快会耗费巨大。
在一些电脑游戏里，一个存档真的包含在一个充满文件的目录里。这些游戏为玩家屏蔽 了这些细节，并提供一个方便易用的界面来管理该目录的不同版本。
版本控制系统也没有两样。两者提供友好的界面，来管理目录里的东西。你可以频繁保 存，也可以之后加载任一保存。不像大多计算机游戏，版本控制系统通常精于节省存储 空间。一般情况如果两个版本间只有少数文件的变更，每个文件的变更也不大，那就只 存储差异的部分，而不是把全部拷贝的都保存下来，以节省存储空间。
现在设想一个很难的游戏。太难打了，以至于世界各地很多骨灰级玩家决定组队，分享 他们游戏存档以攻克它。Speedrun们就是实际中的例子：在同一个游戏里，玩家们分别 攻克不同的等级，协同工作以创造惊人战绩。
你如何搭建一个系统，使得他们易于得到彼此的存档？并易于上载新的存档？
在过去，每个项目都使用中心式版本控制。某个服务器上放所有保存的游戏记录。其他 人就不用了。每个玩家在他们机器上最多保留几个游戏记录。当一个玩家想更新进度时 候，他们需要把最新进度从主服务器下载下来，玩一会儿，保存并上载到主服务器以供 其他人使用。
假如一个玩家由于某种原因，想得到一个较旧版本的游戏进度怎么样？或许当前保存的...
Git分布式本性使得历史可以轻易编辑。但你若篡改过去，需要小心：只重写你独自拥有 的那部分。正如民族间会无休止的争论谁犯下了什么暴行一样，如果在另一个人的克隆 里，历史版本与你的不同，当你们的树互操作时，你会遇到一致性方面的问题。
一些开发人员强烈地感觉历史应该永远不变，不好的部分也不变所有都不变。另一些觉 得代码树在向外发布之前，应该整得漂漂亮亮的。Git同时支持两者的观点。像克隆，分 支和合并一样，重写历史只是Git给你的另一强大功能，至于如何明智地使用它，那是你 的事了。
刚提交，但你期望你输入的是一条不同的信息？那么键入：
$ git commit --amend来改变上一条信息。意识到你还忘记了加一个文件？运行git add来加，然后运行上面的 命令。
希望在上次提交里包括多一点的改动？那么就做这些改动并运行：
$ git commit --amend -a假设前面的问题还要糟糕十倍。在漫长的时间里我们提交了一堆。但你不太喜欢他们的 组织方式，而且一些提交信息需要重写。那么键入：
$ git rebase -i HEAD~10并且后10个提交会出现在你喜爱的$EDITOR。一个例子：
pick 5c6eb73 Added repo.or.cz link...我们揭开Git神秘面纱，往里瞧瞧它是如何创造奇迹的。我会跳过细节。更深入的描述参 见 用户手 册。
Git怎么这么谦逊寡言呢？除了偶尔提交和合并外，你可以如常工作，就像不知道版本控 制系统存在一样。那就是，直到你需要它的时候，而且那是你欢欣的时候，Git一直默默 注视着你。
其他版本控制系统强迫你与繁文缛节和官僚主义不断斗争。文件的权限可能是只读的， 除非你显式地告诉中心服务器哪些文件你打算编辑。即使最基本的命令，随着用户数目 的增多，也会慢的像爬一样。中心服务器可能正跟踪什么人，什么时候check out了什么 代码。当网络连接断了的时候，你就遭殃了。开发人员不断地与这些版本控制系统的种 种限制作斗争。一旦网络或中心服务器瘫痪，工作就嘎然而止。
与之相反，Git简单地在你工作目录下的.git目录保存你项目的历史。这是你自己的历 史拷贝，因此你可以保持离线，直到你想和他人沟通为止。你拥有你的文件命运完全的 控制权，因为Git可以轻易在任何时候从.git重建一个保存状态。
很多人把加密和保持信息机密关联起来，但一个同等重要的目标是保证信息安全。合理 使用哈希加密功能可以防止无意或有意的数据损坏行为。
一个SHA1哈希值可被认为是一个唯一的160位ID数，用它可以唯一标识你一生中遇到的每 个字节串。 实际上不止如此：每个字节串可供任何人用好多辈子。
对一个文件而言，其整体内容的哈希值可以被看作这个文件的唯一标识ID数。
因为一个SHA1哈希值本身也是一个字节串，我们可以哈希包括其他哈希值的字节串。这 个简单的观察出奇地有用：查看“哈希链”。我们之后会看Git如何利用这一点来高效地 保证数据完整性。
简言之，Git把你数据保存在.git/objects子目录，那里看不到正常文件名，相反你只 看到ID。通过用ID作为文件名，加上一些文件锁和时间戳技巧，Git把任意一个原始的文 件系统转化为一个高效而稳定的数据库。
Git是如何知道你重命名了一个文件，即使你从来没有明确提及这个事实？当然，你或许 是运行了 git...
Ben Lynn 2007年8月
Git 堪称版本控制瑞士军刀。这个可靠、多才多艺、用途多样的校 订工具异常灵活，以致不易掌握，更别说精通了。
正如Arthur C. Clarke所说，足够先进的技术与魔法无二。这是学习Git的好办法：新手 不妨忽略Git的内部机理，只当小把戏玩，借助Git其奇妙的能力，逗逗朋友，气气敌人。
为了不陷入细节，我们对特定功能提供大面上的讲解。在反复应用之后，慢慢地你会理 解每个小技巧如何工作，以及如何组合这些技巧以满足你的需求。
.翻译