Mercurial 与 Git 对比

为什么要比较 Mercurial 和 Git？

版本控制系统 (VCS) 在 DevOps 团队启动、保持工作效率和速度或提高团队表现方面发挥着关键作用。有效的 VCS 不仅需要支持 DevOps 所需的常规操作 – 跟踪变更、记录更新、合并数据等 – 而且还会一直为开发人员所用，因此它必须具有满足团队需求的功能，如：可理解的命令语法、变更可见性等。

过去 10 年中，较为广泛采用的模式是分布式 VCS。在这种模式下，单一来源的真相库副本被共享或克隆到不同的系统中，如：开发人员的笔记本电脑，在本地变更后，再按预定义的模式（如基于中继的模式）将数据合并到真相源。其中两种著名的分布式 VCS 解决方案就是 Mercurial 和 Git。这两种方案都是在 2005 年基于 GNU 通用公共许可证 (GPL) 发布，二者存在一定相似性，同时又有一些差异，处于良好竞争状态，均得到了广泛应用。今天让我们来比较梳理一下 Mercurial 和 Git 吧。

Mercurial

Mercurial 是一种分布式 CVS，支持保存仓库到本地，然后再将变更合并到集中化版本。

Mercurial 的命令语法设计非常简单，便于用户快速理解。许多用户都认为这种语法更简单、更直观，有助于提高开发速度。基本命令包括：

hg init：创建新的仓库
hg commit：保存变更到当前仓库
hg log：查看仓库中的所有变更
hg pull：将其它仓库中的所有变更带入当前库
hg push：将当前仓库中的所有变更发送到其它仓库
hg serve：创建协作人员可以查看历史并从中拉取数据的 Web 服务器
hg merge：加入不同历史线

随着时间推移，在名为修订日志 (RevlogNG) 的数据结构中，线性跟踪各种变更情况。修订日志结构允许 Mercurial 用户在任意时间点与仓库内容交互。这种变更跟踪的方法对于文件数量和贡献者数量众多的项目尤其有效。这在选择 Mercurial 作为其 VCS 的项目都有体现，如 Mozilla 和 NGINX。

变更一旦记录到 Mercurial 历史中，就保持固定不变，不能删除，除非通过回退，以相似的方式记录为新的变更。在确定变更入库的时间和入库人员时，此类永久记录极具价值。

Git

Git 是一种分布式 CVS，支持保存仓库到本地，然后再将变更合并到集中化版本（是不是听起来很熟悉？）。Linux Torvalds 于 2005 年创建了 Git，以支持世界各地开发者对 Linux kernel 的持续开发。

仓库的基本 Git 命令包括：

git init / git clone：用于创建新的仓库或复制现有仓库
git add：新增 Git 可跟踪的文件和目录；新文件或目录默认不可跟踪
git commit：将仓库中对象的当前状态记录到 commit（提交）中
git status：打印有关当前状态的信息，包括与上一次提交偏离的信息
git branch：用于管理仓库内的本地和远程分支
git checkout：从当前分支切换到其它指定分支，如果指定分支不存在，创建新的分支
git merge：新增分支历史到其它分支
git push：将所有提交历史上传到远程库中
git pull：下载当前分支的远程分支，并合并变更到本地版本中

除了这些基本命令外，Git 还有几项命令，可以实现更专业的操作，如：

git config
git diff
git reset
git rm
git log
git show
git tag
git remote
git stash

提交是 Git 的基本操作单元，通过 SHA-1 散列进行明确跟踪。在后台，Git 利用一系列参考来跟踪相互之间的提交，并将各提交的内容编入索引。

Git 的重点是在计算和哲学上进行轻量级廉价的提交操作。通过设计，这种方法可以触发多次提交，特别是在大型分支合并时，Git 具有“变基”的能力，可以从逻辑上将一系列提交折叠为单个提交。这就像是，“所有提交的工作都是一次性完成的”。这是一种重写历史的形式。显然所有变更并非一次性完成，但各变更相对于其它变更的上下文都是折叠、扁平的。

相关文献： C++ 项目中 GitHub Actions 的使用