D.1   面对面访谈录

Git：你好 Hg，我发现我们真的很像。

Hg：是啊，人们把我们都归类为分布式版本控制工具，所以我们之间的相似度，要比和 CVS、SVN 的相似度高得多了。

Hg：我是用 Python 和少部分的 C 语言实现的，你呢？

Git：我的核心当然是使用 C 语言了，因为 Linus Torvalds 最爱用 C 语言了。我的很多命令还使用了 Shell 脚本和 Perl 语言开发，Python 用的很少。

Hg：大量的使用 C 语言，是你的性能比我高的原因么？

Git：当然不是了，你不也在核心模块使用 C 语言了么？问题的关键在于我的对象库设计的非常优秀。你不要忘了我是谁发明的，可是大名鼎鼎的 Linux 之父 Linus Tolvars，他对 Linux 文件系统可是再熟悉不过的了，所以他能够以文件系统开发者的视角实现我的核心。

Git：还有我的网络传输过程非常直观，可以显示实时的进度，好像我从你那里没有看到。之所以我能够有这样的实现，是因为我使用了“智能协议”。在网络传输的两端都启用了相应的辅助程序，实现差异传输及传输进度的计算和显示。

Hg：是啊，非常的惭愧。当克隆一个比较大的 Hg 版本库时，会出现假死状态，用户不知道克隆操作的进展。（感谢来自台湾的 Willie Wu，指出我的错误）

Hg：实际上我也支持进度显示，不过是通过Progress插件实现的，需要通过修改配置文件启用该插件。

Hg：我有一个特点是 SVN 用户非常喜欢的，就是我的顺序数字版本号。

Git：你的顺序数字版本号只在本地版本库中有效。也就是说，你不能像 SVN 那样将顺序数字版本号作为项目本身的版本号，因为换成另外一个版本库的克隆，那个数字版本号就会不一样了。

Hg：我觉得你的暂存区（stage）的概念太古怪了。我提交的时候，改动的文件会直接提交而不需要什么注册到暂存区的操作。

Git：让读者来作评判吧。如果读者读过本书的第2篇，一定会说 Git 的暂存区帅呆了。

Hg：我只允许用户对最近的一次提交进行回滚撤销，而你（Git）怎么能允许用户撤销任意多次历史提交呢？那样安全么？

Git：这就是的我对象库和引用设计的强大之处，我可以使用 git reset 命令将工作分支进行任意的重置，丢弃任意多的历史。至于安全性，我的重置命令有一个保险，就是 reflog ，我随时可以参照 reflog 的记录来弥补错误的重置。

Hg：我们的 revert 命令好像不同？

Git：你 Hg 的 hg revert 命令和 SVN 的 svn revert 命令相似，是取消本地修改，用原始拷贝覆盖。你的这个操作在我这里是用 git checkout 命令实现的。我也有一个 git revert 命令，但是这个命令是针对某个历史提交进行反向操作，以取消该历史提交的改动的。

Hg：我执行日志查看能够看到文本显示的分支图，你呢？

Git：我需要在日志显示时添加参数，即用命令 git log –graph 。我支持通过建立别名实现简洁的调用，例如建立一个名为 glog 的别名。

Git：我听说你 Hg 不支持分支？

Hg：坦白的说，是的。我虽然也有分支命令，但是分支不是一个独立显示的提交空间，而是各个分支都显示在一起，相当于在版本库中同时拥有多个头，选择哪个分支就相当于把帽子戴在哪个头上面而已。所以我尽量要求我的用户使用克隆来当做分支。（感谢来自台湾的 Willie Wu，指出我的错误）

Hg：你说的是昨天的我，现在有了Bookmarks插件 ，我也拥有和你类似的分支实现。不过传统来讲我还是以克隆来实现分支的。

Git：实际上我的每一个克隆的版本库也相当于独立的分支，但是因为我有强大的分支功能，因此很多用户还没有意识到。使用 Topgit 的用户就应该使用版本库克隆作为 Topgit 本身的分支管理。

Git：还有，因为我对分支的完整支持，使得我可以和 SVN 很好的协同工作。我可以将整个 SVN 转换为本地的 Git 库，但是你 Hg，显然只能每次转换一个分支。

Hg：是的，我要向你多学习。

B.1   面对面访谈录

Git：我的提交是原子提交。每次提交都对应于一个目录树（树对象）。因为我的提交ID是对目录树及相关的提交信息建立的一个SHA1哈希值，所以可以保证数据的完整性。

CVS：我承认这是我的软肋，一次错误或冲突的提交会导致部分数据被提交，而部分数据没有提交，版本库完整性被破坏，所以人们才设计出来 Subversion（SVN） 来取代我。

Git：我的分支和里程碑管理非常快捷。因为我的分支和里程碑就是一个记录提交ID的引用，你的呢？

CVS：你怎么又提到别人的痛处了！我的分支和里程碑创建速度还是很快的，…嗯… ， 如果在版本库中只有几个文件的话。当然如果版本库的文件的很多，创建分支、里程碑创建就需要花费更多的时间。有些人对此忍无可忍，于是设计出 SVN 来取代我。

Git：其实我不用里程碑都没有关系，因为每一个提交ID就对应于唯一的一个提交状态。

CVS：这也是我做不到的。我没有全局版本号的概念，每一个文件都通过单独的版本号记录其变更历史，所以人们在使用我的时候必须经常地用里程碑 （tag）对我的状态进行标识。还需要提醒一句，如果版本库中文件太多，创建里程碑是很耗时的，因为要一一打开每一个版本库中的文件，在其中记录里程碑和 文件版本的关系。

Git：我的工作区很干净。只在工作区的根目录下有一个 .git 目录，此外再无其他辅助目录或文件。

CVS：我要在工作区的每一个目录下都放置一个 CVS 目录，这个目录下有个Entries 文件很重要，记录了对应工作区文件的检出版本以及时间戳等信息。这样做的好处是可以将工作区移动到任何其他磁盘和目录，依然可以使用，甚至我可以将工作区的一个子目录拿出来，作为独立的工作区。

Git：我也可以将工作区移动到其他磁盘，但是要保证工作区下的 .git 目录和工作区一同移动。也不可以只移动工作区下的一个目录到其他磁盘或目录，那样的话移出的目录就不能工作了。

Git：我的网络传输效率很高。在和其他版本库交互时，对方会告诉我他有什么，我也知道我有什么，因为只对缺失对象的打包传输，所以效率很高而且能够显示传输进度。

CVS：这一点我不行。因为我本地没有文件做对照，所以我在传输的时候不可能做到增量传输。

Git：我甚至可以不需要网络，因为我在本地拥有完整的版本库，几乎所有操作都是在本地完成。

CVS：我的操作处处需要网络，如果版本库是在网络中其他服务器上的话。如果网速比较慢，查看日志、查看历史版本都需要花费很长时间等待。

CVS：你怎么没有更新（update）命令？还有你为什么老是要执行检出命令（checkout）？对我而言，检出命令只在工作区创建时一次完成的。

Git：你的检出命令（checkout）是从远程版本库服务器获取数据完成本地工作区的创建，版本库仍然位于远程的服务器上。你 的更新（update）命令执行的很慢对么？之所以你需要执行更新命令是因为你的版本库在远程啊。别忘了我的版本库是在本地，我的每一步操作工作区和版本 库都是同步的，所以更新操作就没有存在的必要了。而我的检出（checkout）操作是将本地版本库的数据检出到本地工作区，用于恢复本地丢失的文件或错 误改动的文件，也用于切换不同的分支。我也有一个和你的更新（update）操作类似的比较耗时的网络操作命令叫做 git fetch 或 git pull，这两个操作是从别人的版本库获取他人改动。一般使用我（Git）做团队协作的时候，会部署一个集中共享的版本库，我就用这两个命令（git fetch 或 git pull）从共享的版本库执行拉回操作。也也许你（CVS）会觉得 git fetch 或者 git pull 和你的 cvs update 命令更像吧。至于你的检出命令（cvs checkout），实际上和我克隆命令（git clone）很相似，只不过我的克隆命令不但创建了本地工作区，而且在本地还复制了和远程版本库一样的本地版本库。

CVS：为什么你的检入命令（commit）命令执行的那么快？

Git：是的，我的检入命令飞一般就执行完了，也是因为版本库就在本地。也许你（CVS）会觉得我的推送命令（git push）和你的检入命令（cvs commit）更相像，其实这是一个误会。如果我不做本地提交，是不能通过推送命令（git push）将我的本地的提交共享给（推送给）其他版本库的。你（CVS）每一次提交都要和版本库进行网络通讯，而我可以在本地版本库进行多次提交，直到我 的主人想喝咖啡了才执行一次 git push，将我本地版本库中新的提交推送给远程版本库。

CVS：我每一个文件都一个独立的版本号，你有么？

Git：每一个文件一个版本号？这有什么值得夸耀的？我听说你最早是用脚本对 RCS 系统进行封装实现的，所以你每个文件都有一个独立的版本控制，这让你变得很零碎。我听说某些商业版本控制系统也是这样，真糟糕。我的每一次提交都有一个全 球唯一的版本号，这样不但是在本地版本库中是唯一的，和其他人的版本库也不会有冲突。

CVS：我能一次检出一个目录，你好像不能吧？

Git：所以我有子模组，以及 repo 等第三方工具，可以帮助我把一个大的版本库拆开多个版本库组合来使用啊。

CVS：我能添加空目录，你好像不能吧！

Git：是的，我现在还不能记录空目录。但是用户可以在空目录下创建一个隐含文件，并将该隐含文件添加到版本库中，也就实现了空目录添加的功能。你，CVS，目录管理是你的软肋，你很难实现目录的重命名，而目录重命名对我来说是小菜一碟。