我一直在使用 Mercurial，但想快速演示一下 Git。
什么是 Git 等价物：
hg init . # start a project in the current directory
hg addremove # look for any added or deleted files
hg commit -m "comment" # commit any uncomitted changes
hg status # what have i changed since the last commit?
【问题讨论】：
The Git-HG rosetta stone is not bad
这两者之间还有一些其他的陷阱没有提到。当我走另一条路（git -> hg）时，这个列表是从我自己的博客文章中抄来的。
Hg .hgignore，语法：glob 与 git 的 .gitignore 行为相同。
Git .git/config, ~/.gitconfig, 使用 git-config 修改值
Hg .hg/hgrc, ~/.hgrc, 使用hg help -c config
Git git commit -v<br>
汞 hg diff | less; hg commit
Git gitk<br>
汞 hg view, or thg from [TortoiseHg][1]
Git git gui<br>
Hg Mercurial 不提供 GUI 来选择变更集，只有控制台 hg record 命令。
Git git rebase<br>
汞 hg rebase。对于git rebase --interactive，有hg histedit，或Mercurial Queues
Git git push URL ; git remote add origin URL<br>
汞 hg push URL; $EDITOR .hg/hgrc ; [paths] default = URL
Git gitk, git log origin/master..HEAD<br>
汞 hg outgoing
Git git format-patch RANGE<br>
汞 hg email -m filename -o
Git git add . ; 注意点
Hg hg add ; 不需要点。
Git git checkout REVISION-KEY<br>
汞 hg update CHANGESET
只是为了填补空白，Mercurial 的一些最有用的命令：
Hg hg record
Git git add -p; git commit
Hg hg inc [URL]
Git 没有真正的等价物。你只能做相当于hg pull; hg log -r .:
Hg hg out URL
Git如果你知道请添加。
为了解决合并冲突，Mercurial 中的 hg resolve 命令有几个选项可以改变行为：
Hg hg resolve -m FILE（将文件标记为已通过手动修复冲突问题解决）
Git git add FILE
Hg hg resolve -u FILE 将文件标记为未解析
Git git reset HEAD FILE 取消暂存文件
Hg hg resolve -l（列出已解决/未解决冲突的文件）
Git git status - 干净合并的文件会自动添加到索引中，那些没有冲突
Hg hg resolve FILE（合并后，尝试重新合并文件）
Git据我所知没有重新合并的等效项。
【讨论】：
hg record不是很人性化，但hg crecord（来自crecord extension）是一个基于curses的文本UI，使用起来非常方便。
hg resolve 的默认操作是我更喜欢 git 的原因之一。默认情况下，hg resolve 会破坏您手动解析的合并，如果您不传递任何参数！
注意：Git 和 Mercurial 之间最大的区别之一是明确存在 index 或 staging area。
Git 是唯一公开索引或暂存区概念的DistributedSCM。其他人可能会实现并隐藏它，但在其他情况下用户不会意识到也不必处理它。
Mercurial 的粗略等价物是
DirState，它控制工作副本状态信息以确定要包含在下一次提交中的文件。但无论如何，这个文件是自动处理的。
此外，通过在命令行上指定要提交的文件或使用RecordExtension，可以在提交时更有选择性。如果您在处理索引时感到不舒服，那么您正在转向更好;-)
诀窍是，您确实需要了解索引才能充分利用 Git。正如article from May 2006当时提醒我们的那样（现在仍然如此）：
“如果你否认索引，你真的否认了 git 本身。”
现在，那篇文章包含许多现在更易于使用的命令（所以不要过分依赖它的内容；）），但总体思路仍然存在：
您正在开发一项新功能并开始对文件进行少量修改。
# working, add a few lines
$ git add myFile
# working, another minor modification
$ git add myFile
此时，您的下一次提交将在当前分支中进行 2 次小修改
# working, making major modification for the new features
# ... damn! I cannot commit all this in the current branch: nothing would work
$ git commit
仅记录此时添加到暂存区（索引）的更改，不记录当前在您的工作目录中可见的主要更改。
$ git branch newFeature_Branch
$ git add myFile
下一次提交将记录新分支“newFrature_Branch”中的所有其他主要更改。
现在，通过“hg record”命令或其他扩展，以交互方式添加甚至拆分提交是 Mercurial 提供的功能：您需要安装 RecordExtension 或 CrecordExtension。
但这不是 Mercurial 正常工作流程的一部分。
Git 将提交视为一系列“文件内容更改”，并允许您一次添加这些更改。
您应该研究该功能及其后果：Git 的大部分功能（例如轻松revert a merge (or bisect the problem, or revert a commit)、contrary to Mercurial 的能力）来自“文件内容”范式。
tonfa（在个人资料中：“Hg dev，pythonist”：数字...）在 cmets 中插话：
索引中根本没有什么“git-ish”，如果它被认为有价值，hg 可以使用索引，事实上
mq或shelve已经做了一部分。
哦，孩子。我们又来了。
首先，我不是为了让一个工具看起来比另一个更好。我发现 Hg 很棒，非常直观，有很好的支持（尤其是在我的主要平台 Windows 上，尽管我也在 Linux 和 Solaris8 或 10 上工作）。
索引实际上在前面和中间Linus Torvalds works with a VCS：
Git 从第一天开始就使用显式索引更新，甚至在它进行第一次合并之前。这就是我一直以来的工作方式。我倾向于有脏树，在我的树中有一些随机补丁，我确实不想想要提交，因为它只是下一个版本的 Makefile 更新
现在索引的组合（这不是仅在Git中看到的概念），和“内容为王”范式使其成为pretty unique and "git-ish"：
git 是一个内容跟踪器，一个文件名没有任何意义，除非与它的内容相关联。因此， git add filename 唯一合理的行为是将文件的内容及其名称添加到索引中。
注意："content", here, is defined as follows：
Git的索引基本定义为
- 足以包含树的全部“内容”（这包括所有元数据：文件名、模式和文件内容都是部分 的“内容”，它们本身就毫无意义！）
- 额外的“统计”信息，以实现明显且微不足道（但非常重要！）的文件系统比较优化。
所以你真的应该将索引视为内容。
内容不是“文件名”或“文件内容”作为单独的部分。你真的不能把两者分开。
文件名本身没有意义（它们也必须有文件内容），文件内容本身也同样没有意义（你必须知道如何访问它）。我想说的是，git 从根本上不会允许您看到没有内容的文件名。整个概念是疯狂且无效的。它与“现实”无关。
来自the FAQ，主要优点是：
git diff 所做的操作，并使用 git add 或 git add -u 验证每个小步骤。git diff --base、git diff --ours、git diff --theirs。 git commit --amend在同时没有修改索引的情况下只修改日志消息我个人认为这种行为不应该是默认行为，您希望人们提交经过测试或至少编译的内容
虽然您总体上是对的（关于“测试或编译”部分），但 Git 允许您进行分支和合并（樱桃采摘或变基）的方式允许您在临时私有分支中尽可能频繁地提交（仅推送到远程“备份”存储库），同时在公共分支上重新执行那些“丑陋的提交”，并进行所有正确的测试。
【讨论】：
水银：
hg init . # start a project in the current directory
hg addremove # look for any added or deleted files
hg commit -m "comment" # commit any uncomitted changes
hg status # what have i changed since the last commit?
Git 等价物：
git init
git add -A
git commit -am "comment" # -a is not necessary along with the above add -A
git status
【讨论】：
git add -u 比使用 -A 多； -u 将暂存所有跟踪文件的更改，忽略新的未跟踪文件。
git status 等同于hg status。我是 Hg 的新手，并没有设法让 hg 的状态工作类似于 Git。
大致相同，没有addremove：
git init # Start a project in the current directory
git status # Displays both changes and added/removed files
git commit -m "comment" # commit any uncommited changes
但是，这些是您在单独工作时会使用的命令。当您想使用 git pull 和 git push 以及相关命令将您的更改与其他人的工作合并时，您会进入整洁的内容。
【讨论】：