为什么Git需要设计Index / Stage？

Question

下图是Git流程图，我很奇怪为什么Git需要设计 Index / Stage 。

您知道存储库和 Workspace 之间的通信是本地的，很容易在存储库和 Workspace 之间进行提交或回滚 em>。

为什么Git需要设计Index / Stage？

图片

Answer 1

这是即将进行的更改的预览。您可以逐步地或一次性地在此专用空间中构成将来的提交，检查其中的内容，然后仅在对内容满意时才提交。

有些人几乎忽略了它的存在，从不使用add，而是依靠-a来盲目添加所有内容，但是这被认为是不好的做法，因为在更复杂的情况下，这会造成将来的麻烦在这种情况下，对索引 的理解将至关重要。

我建议您查看this条文章中的other。

Answer 2

已暂存的文件用作显示，供提交者查看要添加到该特定提交的更改。它也有助于键入git commit -a，这是@Romain提到的一种不好的做法。

下面是另一个用例， 您在a.txt和b.txt中进行了更改，但是出于各种原因（可能将a.txt推送到另一个分支，将b.txt推送到另一个分支！），都需要对这些文件执行两次单独的提交。想象一下要承担的工作！

拥有索引文件只会使开发人员的工作变得轻松，这不是一个盲目的设计决定。

Answer 3

Mercurial是存在证明，不需要Git的索引/暂存区域。 Mercurial和Git具有同样强大的功能（至少就存储修订而言），但是在Mercurial中，工作树 是暂存区/建议的下一个提交。在Git中，工作树无关紧要，索引是暂存区/建议的下一次提交。

也就是说，Git比Mercurial快得多。这种速度的很大一部分是因为Git保持了其单独的索引（尽管很多也归因于Mercurial在Python中而不是C中的实现）。因此，如果可以的话，索引的存在可以使Git变得“快速”。

虽然有些人发现烦恼的地方是单独的暂存区，但正如您在其他答案中所看到的那样，其他人则发现此暂存区非常方便。特别是，您可以分阶段进行工作-将文件的某个版本从工作树复制到暂存区中-然后进一步或以其他方式修改工作树文件，例如添加不在目录中的调试信息。 -提交该文件的副本。使用git add -p和git reset -p，您可以添加和删除特定的修复程序，同时使调试部分在工作树中仅存在 。

因此，这提供了建立索引的两个动机：您可以拥有一个与工作树故意不同的暂存区域，并且Git的运行速度更快，因为 Git的暂存区域为已经适合提交。 （Mercurial的不是随时可以提交：必须首先将工作树按摩成适合提交的形式，并且无论哪种语言实现了按摩或您为此问题投入了多少缓存，仍然需要一些计算工作。）

一旦您了解了一个单独临时区域的想法，它就会提供第三种动力：现在，如果对某些特定目的有用，您可以随时创建其他临时区域。例如，git stash就是这样实现的。 （它也与git worktree add有关，尽管其他工作树作为对添加了：您会得到一个带有新索引的新工作树。如果有的话，这表明新工作-tree应该成为新索引，即Mercurial模型更好！）