纵观 2022 年版本控制领域的基本格局，其实不难理解为什么分布式版本控制成了软件开发者们的首选方案。但是，为什么 Git 的市场份额会比 Mercurial 大那么多？它们的诞生时间相似、功能配置接近，颇有种既生瑜、何生亮之感。Brase 给出的理由是，“对于个人项目，我会选择 Mercurial。但如果是要创办一家公司，我会使用 Git 来避免重新培训和新人难上手等问题。”

Mercurial 当然也有自己的优势，SVN 用户对它的设计和集中式操作会感觉非常熟悉。VonC 表示，“Mercurial 其实上手更快、用起来感觉更熟悉，因为它跟 Subversion 有那么几分相似，只是采用了分布式模型。”但这种过于忠实旧时光的思路未必就是好事，“这也成了反对者拒绝 Mercurial 的理由，因为在去中心化开发成为主流的今天，在分布式模型外面套上传统工具的壳子实在没什么必要。”

至于 Git 为什么能压倒性胜出，也许可以简单归结为强大的平台与可观的首发用户群体。Gomès 和 David 坦言，“Mercurial 之所以在 2010 年代之初输给了 Git，一方面是因为当时 GitHub 的飞速发展，另一方面是因为 Linux 社区对 Git 拥有天然认同。”

尽管 Mercurial 最初也占据了一点有利位置，但随着时间推移，这种优势逐渐消散。Brase 认为，“Mercurial 的最初定位是通过内置的 Web UI 提供精心设计且连贯顺畅的用户体验。GitHub 虽然没能为 Git 提供同等水平的 Web 用户界面和连贯性，但庞大的贡献者群体和创始者的感召力最终牢牢压制住了 Mercurial。”

庞大贡献者群体所对应的，自然就是“雪崩”般的功能发布；再加上对用户需求的关注，无疑让 Git 顺利斩获可观的市场份额。近 15 年前，曾经有人将 Git 比作是“百战天龙”（特别擅长用身边小物件达成意外惊喜的特工片主角），而 Mercurial 则更像“007”。只要熟悉命令行，那 Git 能帮我们为几乎一切问题拼凑出定制化解决方案；而 Mercurial 相对更挑工作，如果合适则更加快速高效。面对现状，他的最新观点是“我当初对 Git 的用户界面最不满意，但它在多年的发展中逐步做出了改进（我现在用的是基于 Emacs 的 Git 前端，体验很好）；而 Mercurial 的主要缺点是在大型代码仓库上执行程度很慢，而且直到现在也没能解决。”

与“百战天龙”中的 MacGyver 一样，Git 一直在即兴发挥、迎接挑战。而如同 007 的经典男主 James Bond，Mercurial 也坚持着自己的行事风格——在某些情况下效果很好，但有时候则相当拉胯。Brase 认为，“我们可以通过一个例子来体会 Git 和 Mercurial 在处理新功能时的差别，即「config」命令。「git config」和「hg config」都是用于编辑用户邮件地址等设置的命令。「git config」命令会自动为用户修改「~/.gitrc」，而且大多数情况下是正确的。Mercurial 的缔造者则坚决拒绝一切会编辑配置文件的提交贡献。相反，「hg config」只会在「~/.hgrc」上启动文本编辑器。这就像在嘲讽我们，被文本配置文件吓倒的程序员，就像是会晕血的医生——统统不合格。”


总而言之，虽然 Git 好像已经成了版本控制市场上的独苗，但这个世界总有更多解决问题的办法，如果大家对目前的某些选项感到沮丧，不妨再多探究一番。一定还有别的途径，一定还有其他值得学习的新思路。