Git相当于汞添加+汞差异？

我最近习惯了水银后开始使用git。

从本质上讲，如果我hg add有一些文件，那么hg diff我会得到一个补丁，然后可以从理论上应用一个简单的补丁，patch -p1并获得完全相同的本地副本。

现在，有了git，情况就不同了：在您git diff之前git add。但是，我该如何git diff覆盖ing hg diff之后的所有未跟踪文件hg add呢？

TL; DR：添加所有内容，然后运行git diff --cached

Mercurial和Git在这里有不同的哲学。Git显式公开了Git所谓的索引。Mercurial没有索引（它在内部具有相似的东西，但是不公开它，因此您甚至不必知道它的存在）。许多喜欢Git的人认为暴露指数非常好，并且许多诅咒Git的人都认为可怕。:-)尽管如此，这就是您正在遇到的问题，如果您使用的是Git，那么您正在使用索引，因此现在该学习它是什么以及如何处理它了。

因此，让我们定义“索引”。Git的索引（也称为暂存区，有时也称为缓存）是一个复杂的小野兽，具有许多Git 通常不会暴露的隐藏方面。但是，它确实有一个简单的定义，您需要知道：在此构建下一个提交的make。

这里值得一提的是Git和Mercurial之间的另一个区别。Mercurial存储变更（技术变更集），而Git存储快照。在大多数情况下，这并没有真正的区别。快照很容易转换为变更集：只需将快照与其父对象进行比较即可。给定父级快照，更改集可以轻松转换为新快照：只需应用更改集即可。但是，应用很长的变更集链很慢，因此Mercurial会定期存储快照。它会在后台执行所有这些操作，而您不必意识到这一点。像往常一样，Git暴露了所有东西（有点像闪光器或裸奔者 这样一来，赤裸裸地跑来跑去，露出没人想看到的晃来晃去的东西。

运行时git commit，Git会将索引中的任何内容转换为提交快照。因此git add将文件放入索引。如果文件已经存在，请git add使用从工作树中获取的新版本替换现有副本。如果文件尚不存在，git add请将工作树版本作为新文件放入索引。无论哪种方式，索引版本现在都可以更新（暂存）并准备好进入下一个快照。

举一个文件进行索引，您可以运行git rm。这从文件中删除这两个指标和工作树。或者，您可以运行git rm --cached，仅将其移出索引，然后将其保留在工作树中（但请注意，因为这可能会成为将来的陷阱）。

现在，由于索引/临时区域/缓存是这样暴露的，因此可以git diff。为此，请使用git diff --cached或git diff --staged（它们具有完全相同的含义；我通常坚持使用，--cached因为git rmhas --cached却没有--staged）。

问题在于，这仅差异索引中已更新的文件。更准确地说，它运行的等效项git diff HEAD ，即，它将当前提交与索引的内容进行比较。这意味着您在工作树中已修改但尚未暂存的任何文件都不会进行比较。但是，解决方案很简单：只有git add那些文件。

撇开：.gitignore未追踪与被忽略

一次添加一堆文件很麻烦，因此您可能要使用git add .或git add -A（它们有些微不同；请参见其他StackOverflow问题和解答，并请注意，Git 2.0版发生了很大变化，影响了-A此处的选项）。然而，你的工作树经常有你的文件不希望添加，这就是当我们进入未经跟踪VS未经跟踪和忽视的文件。

现在我们知道索引是什么了，对于Git而言，未跟踪文件的定义非常简短。未跟踪的文件是不在索引中的文件。就是这样，仅此而已。如果在索引中，则会对其进行跟踪。如果不是，则不是。

但是，当然有一个复杂的问题（Mercurial中也有）：如果您有一堆未跟踪的文件，则版本控制系统会对它们产生很多抱怨。要关闭它，您可以向添加文件名或全局模式.gitignore。请注意，与Mercurial不同，您不能将正规表达式添加到.gitignore，只能添加全局模式。这既是好（glob模式是远远更容易得到右）和差（glob模式是不一样强大的完整的正则表达式），但在任何情况下，它是什么。^1个

列出的文件.gitignore不会使用git add -A或自动添加git add .。但是，列出文件.gitignore并不会使其无法跟踪。使文件无法跟踪 的唯一原因是它不在索引中。如果您不小心使文件进入了不应跟踪的索引，则必须git rm从索引中获取该文件。

撇开：强大的索引功能可以为您提供

从Mercurial迁移到Git的人们通常最初确实讨厌该指数。使它对许多人更可口的一件事是git add -p。某些人对此根本没有用，但是对于那些这样做的人，这实际上是相当不错的。

Git为您提供的“添加到索引中的内容，将在下一次提交中”和“工作树中的内容”之间的分隔意味着您可以签出分支，出于调试目的而修改某些项目，其他项目（在相同或单独的文件中）来解决问题或添加功能，然后有选择地仅添加错误修复或新功能，而不添加调试更改。

当你git commit的结果，你会得到一个提交一个只具有错误修复或新功能，而不是额外的调试。

通常，这既有优点也有缺点。例如，很难确保您刚刚提交的内容确实有效。也许只有额外的调试才能使它工作。也许您忘记了git add其中的一部分。但是，由于Git鼓励“修改”和重写commits ²，并使commit 和branch 确实便宜，因此您可以在Git中使用不同于Mercurial的方法。Mercurial分支较重，其提交和重新设置基数也hg histedit很慢，这不鼓励这种快速而松散的commit-recommit-rebase-fixup-squash工作。强烈Git的恩 courages这一点。您应该以不同的方式使用Git，在许多临时分支上进行大量临时提交。你不有 尝试，但这是一个好主意。

¹ Mercurial在中支持glob模式和正则表达式.hgignore。不幸的是，在实践中正则表达式（很难正确使用）比全局模式要快得多。我曾让同事将glob改为regexp以提高速度，但后来弄错了。如果要将glob模式转换为正则表达式，请记住将其锚定，并当心.！

²在Mercurial和Git中，提交都是永久性的。但是，两者都提供历史记录编辑和commit --amend。它们以不同的方式到达那里：Git通过复制旧提交来提交新提交，并移动分支名称以指向新提交。这将在存储库中创建“废弃”对象。Git使用它所谓的reflog保留它们一段时间，以便您可以在需要时对其进行恢复，然后最终使reflog条目到期，并“垃圾收集”剩余的垃圾以完全清除它。

Mercurial实际上无法做到这一点，因此，它“剥离”变更集，将其放入剥离备份导出的变更集文件中。然后，如果需要它们可以重新导入它们。这比Git的“重写历史记录”方法的松散-松散的“提交，重新提交，移动分支指针，放弃旧对象”方法要慢得多。由于Git的方法成本较低，在时间和空间方面，做暂时性的提交，你会重写往往非常接近免费的，但是这并不取决于“宽松对象”文件大小-这是更值得的做这在Git中。