最常见的 Mercurial 命令的 Git 等价物？

Git equivalents of most common Mercurial commands?

提问by bouy

I've been using Mercurial but would like to do a quick demo of Git.

我一直在使用 Mercurial，但想要做一个 Git 的快速演示。

What are the Git equivalents of:

什么是 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?

回答by richq

The Git-HG rosetta stone is not bad

Git-HG 罗塞塔石碑不错

There are a few other gotchas between the two not mentioned there. This list was cribbed from my own blog post when I went the other way (git -> hg).

两者之间还有一些其他问题没有提到。当我走另一条路（git -> hg）时，这个列表是从我自己的博客文章中抄录的。

Hg.hgignore, syntax: glob is the same behaviour as git's .gitignore.

Hg.hgignore，语法：glob 与 git 的 .gitignore 的行为相同。

Git.git/config, ~/.gitconfig, use git-config to modify the values
Hg.hg/hgrc, ~/.hgrc, use hg help -c config

git.git/config, ~/.gitconfig, 使用 git-config 修改值
hg.hg/hgrc, ~/.hgrc, 使用hg help -c config

Gitgit commit -v
Hghg diff | less; hg commit

Gitgit commit -v
Hghg diff | 较少的; 汞提交

Gitgitk
Hghg view, or thg from TortoiseHg

Gitgitk
Hghg 视图，或来自TortoiseHg 的thg

Gitgit gui
HgMercurial doesn't ship GUI to select changesets, only console hg recordcommand.

Gitgit gui
HgMercurial 不提供 GUI 来选择变更集，只有控制台hg record命令。

Gitgit rebase
Hghg rebase. For git rebase --interactivethere's hg histedit, or Mercurial Queues

gitgit rebase
Hg hg rebase。因为git rebase --interactive有hg histedit或 Mercurial Queues

Gitgit push URL ; git remote add origin URL
Hghg push URL; $EDITOR .hg/hgrc ; [paths] default = URL

gitgit push URL ; git remote add origin URL
Hghg push URL; $EDITOR .hg/hgrc ; [路径] 默认 = URL

Gitgitk, git log origin/master..HEAD
Hghg outgoing

Gitgitk, git log origin/master..HEAD
Hghg 输出

Gitgit format-patch RANGE
Hghg email -m filename -o

Gitgit format-patch RANGE
Hghg email -m filename -o

Gitgit add . ; Note the dot
Hghg add ; No dot needed.

gitgit 添加。; 注意点
Hghg add ; 不需要点。

Gitgit checkout REVISION-KEY
Hghg update CHANGESET

Gitgit checkout REVISION-KEY
Hghg update CHANGESET

Just to fill the blanks, some of the most useful commands from Mercurial:

为了填补空白，Mercurial 提供了一些最有用的命令：

Hghg record
Gitgit add -p; git commit

汞Hg的记录
混帐混帐添加-p; 提交

Hghg inc [URL]
GitNo real equivalent. You can only do equivalent of hg pull; hg log -r .:

Hghg inc [URL]
Git没有真正的等价物。你只能做相当于hg pull; hg log -r .:

Hghg out URL
GitPlease add if you know how.

汞Hg的出URL
Git的，如果你懂得请补充。

For merge conflict resolution, the hg resolvecommand in Mercurial has a few options that change the behaviour:

为了解决合并冲突，hg resolveMercurial 中的命令有几个改变行为的选项：

Hghg resolve -m FILE (marks the file as having been resolved by manually fixing up the conflict problem)
Gitgit add FILE

汞Hg的决心-m FILE（文件标记为手动固定了冲突问题已得到解决）
混帐混帐添加文件

Hghg resolve -u FILEmarks the file as having been unresolved
Gitgit reset HEAD FILEto unstage the file

Hghg resolve -u FILE将文件标记为未解析
Gitgit reset HEAD FILE以取消暂存文件

Hghg resolve -l (lists files with resolved/unresolved conflicts)
Gitgit status - files that merged cleanly are added to the index automatically, those that are not have conflicts

汞Hg的决心-l（列表中的文件以解决/未解决的冲突）
混帐混帐状态-即合并干净会自动添加到索引不在文件，这些有冲突

Hghg resolve FILE (after a merge, attempts to re-merge the file)
Gitno equivalent for re-merging that I know of.

Hghg resolve FILE（合并后，尝试重新合并文件）
Git没有我所知道的重新合并等效项。

回答by VonC

Note: one of the biggest difference between Git and Mercurial is the explicit presence of the indexor staging area.

注意：Git 和 Mercurial 之间最大的区别之一是索引或暂存区的显式存在。

From Mercurial for Git User:

来自Mercurial for Git 用户：

Git is the only DistributedSCMthat exposes the concept of index or staging area. The others may implement and hide it, but in no other case the user is aware nor has to deal with it.

Mercurial's rough equivalent is the DirState, which controls working copy status information to determine the files to be included in the next commit. But in any case, this file is handled automatically.
Additionally, it is possible to be more selective at commit time either by specifying the files you want to commit on the command line or by using the RecordExtension.

If you felt uncomfortable dealing with the index, you are switching for the better ;-)

Git 是唯一一个公开索引或暂存区概念的DistributedSCM。其他人可能会实现和隐藏它，但在其他情况下，用户不会知道也不必处理它。

Mercurial 的粗略等效项是DirState，它控制工作副本状态信息以确定要包含在下一次提交中的文件。但无论如何，这个文件是自动处理的。
此外，通过在命令行上指定要提交的文件或使用RecordExtension.

如果您对处理索引感到不舒服，那么您正在变得更好;-)

---

---

The trick is, you really need to understand the index to exploit fully Git. As this article from May 2006reminds us then (and it is still true now):

诀窍是，您确实需要了解索引才能充分利用 Git。正如2006 年 5 月的这篇文章当时提醒我们的那样（现在仍然如此）：

“If you deny the Index, you really deny git itself.”

“如果你否认索引，你就真的否认了 git 本身。”

Now, that article contains many commands which are now simpler to use (so do not rely on its content too much ;) ), but the general idea remains:

现在，该文章包含许多现在更易于使用的命令（因此不要过多依赖其内容 ;)），但总体思路仍然是：

You are working on a new feature and starts to make minor modifications on a file.

您正在开发一项新功能并开始对文件进行细微修改。

# working, add a few lines
$ git add myFile
# working, another minor modification
$ git add myFile

At this point, your next commit will embark 2 minor modifications in the current branch

此时，您的下一次提交将在当前分支中进行 2 次小修改

# working, making major modification for the new features
# ... damn! I cannot commit all this in the current branch: nothing would work

$ git commit

Only records the changes added to the staging area (index) at this point, not the major changes currently visible in your working directory.

只记录此时添加到暂存区（索引）的更改，而不是当前在您的工作目录中可见的主要更改。

$ git branch newFeature_Branch
$ git add myFile

The next commit will record all the other major changes in the new branch 'newFrature_Branch'.

下一次提交将记录新分支“newFrature_Branch”中的所有其他主要更改。

Now, adding interactively or even splitting a commit are features available with Mercurial, through the 'hg record' command or other extensions: you will need to install RecordExtension, or the CrecordExtension.
But this is not part of the normal workflow for Mercurial.

现在，加入交互甚至分裂提交可用的是配有水银，通过“ hg record”命令或其他扩展：你需要安装RecordExtension，或CrecordExtension。
但这不是 Mercurial 正常工作流程的一部分。

Git views a commit as a series of "file contentchanges", and let you add those changes one at a time.
You should study that feature and its consequences: Most of Git power (like the ability to easily revert a merge (or bisect the problem, or revert a commit), contrary to Mercurial) comes from that "file content" paradigm.

Git 将提交视为一系列“文件内容更改”，并让您一次添加一个更改。
您应该研究该功能及其后果：大部分 Git 功能（例如轻松还原合并（或将问题一分为二，或还原提交）的能力，与 Mercurial 不同）来自“文件内容”范式。

---

---

tonfa(in in profile: "Hg dev, pythonist": figures...) chimed in, in the comments:

tonfa（在简介中：“Hg dev，pythonist”：数字......）在评论中插话：

There's nothing fundamentally "git-ish" in the index, hg could use an index if it was deemed valuable, in fact mqor shelvealready do part of that.

索引中根本没有什么“git-ish”，如果索引被认为有价值，实际上mq或shelve已经做了一部分，hg 可以使用它。

Oh boy. Here we go again.

好家伙。又来了。

First, I am not here to make one tool looks better than another. I find Hg great, very intuitive, with a good support (especially on Windows, my main platform, although I work on Linux and Solaris8 or 10 too).

首先，我不是为了让一个工具看起来比另一个更好。我发现 Hg 很棒，非常直观，有很好的支持（尤其是在我的主要平台 Windows 上，尽管我也在 Linux 和 Solaris8 或 10 上工作）。

The index is actually front and center in the way Linus Torvalds works with a VCS:

索引实际上是Linus Torvalds 使用 VCS的方式的前端和中心：

Git used explicit index updates from day 1, even before it did the first merge. It's simply how I've always worked. I tend to have dirty trees, with some random patch in my tree that I do notwant to commit, because it's just a Makefile update for the next version

Git 从第一天开始就使用显式索引更新，甚至在它进行第一次合并之前。这就是我一直以来的工作方式。我往往有脏树，在我的树一些随机的补丁，我不希望提交，因为它只是为下一个版本一个Makefile更新

Now the combinationof the index (which is not a notion seen only in Git), andthe "content is king" paradigm makes it pretty unique and "git-ish":

现在的组合索引（这不仅是在Git中看到的一个概念），并在“内容为王”的模式使得它非常独特，“混帐十岁上下”：

git is a content tracker, and a file name has no meaning unless associated to its content. Therefore, the only sane behavior for git add filename is to add the content of the file as well as its name to the index.

git 是一个内容跟踪器，除非与其内容相关联，否则文件名没有任何意义。因此， git add filename 唯一合理的行为是将文件的内容及其名称添加到索引中。

Note: the "content", here, is defined as follows:

注意：这里的“内容”定义如下：

Git's index is basically very much defined as

• sufficient to contain the total "content" of the tree (and this includes all metadata: the filename, the mode, and the file contents are all partsof the "content", and they are all meaningless on their own!)
• additional "stat" information to allow the obvious and trivial (but hugely important!) filesystem comparison optimizations.

So you really should see the index as beingthe content.

The content is not the "file name" or the "file content" as separate parts. You really cannot separate the two.
Filenames on their own make no sense (they have to have file content too), and file content on its own is similarly senseless (you have to know how to reach it).

What I'm trying to say is that git fundamentally doesn't allowyou to see a filename without its content. The whole notion is insane and not valid. It has no relevance for "reality".

Git 的索引基本上定义为

• 足以容纳总“内容树”（这包括所有的元数据：文件名，模式，文件内容是所有部分！“内容”的，他们对自己的所有意义）
• 额外的“统计”信息，以允许明显和微不足道的（但非常重要！）文件系统比较优化。

所以，你真的应该看到指数是内容。

内容不是作为单独部分的“文件名”或“文件内容”。你真的无法将两者分开。
文件名本身没有意义（它们也必须有文件内容），文件内容本身也同样毫无意义（你必须知道如何访问它）。

我想说的是 git 从根本上不允许你看到没有内容的文件名。整个概念是疯狂的，是无效的。它与“现实”无关。

From the FAQ, the main advantages are:

从FAQ来看，主要优点是：

• commit with a fine granularity
• help you to keep an uncommited modification in your tree for a reasonably long time
• perform several small steps for one commit, checking what you did with git diff, and validating each small step with git addor git add -u.
• allows excellent management of merge conflicts: git diff --base, git diff --ours, git diff --theirs.
• allows git commit --amendto amend only the log message if the index hasn't been modified in the meantime

• 细粒度提交
• 帮助您在相当长的时间内在树中保留未提交的修改
• 为一次提交执行几个小步骤，检查你用 做了什么git diff，并用git add或验证每个小步骤git add -u。
• 允许对合并冲突进行出色的管理：git diff --base, git diff --ours, git diff --theirs.
• git commit --amend如果同时未修改索引，则仅允许修改日志消息

---

---

I personally think this behavior shouldn't be the default, you want people to commit something that is tested or at least compiled

我个人认为这种行为不应该是默认行为，您希望人们提交经过测试或至少编译的内容

While you are right in general (about the "tested or compiled" part), the way Git allows you for branching and merging (cherry-picking or rebasing) allows you to commit as often as you want in a temporary private branch (pushed only to remote "backup" repository), while re-doing those "ugly commits" on a public branch, with all the right tests in place.

虽然您在一般情况下是正确的（关于“测试或编译”部分），但 Git 允许您进行分支和合并（樱桃采摘或变基）的方式允许您在临时私有分支中随时提交（仅推送）到远程“备份”存储库），同时在公共分支上重新执行那些“丑陋的提交”，并进行所有正确的测试。

回答by Dustin

Mercurial:

水银：

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 Equivalents:

Git 等效项：

git init
git add -A
git commit -am "comment" # -a is not necessary along with the above add -A
git status

回答by Fragsworth

It is roughly the same, without addremove:

大致相同，没有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

However, these are commands you would use when working alone. You get into the neatstuff when you want to merge your changes with other people's work with git pulland git push, and related commands.

但是，这些是您单独工作时会使用的命令。当您想使用和以及相关命令将您的更改与其他人的工作合并时，您会进入整洁的东西。git pullgit push