为什么Git需要设计Index/Stage？
Why does Git need to design Index /Stage?
下图是Git流程图，很奇怪为什么Git需要设计Index /Stage.
你知道 Repository 和 Workspace 之间的通信是本地的，Repository[ 之间的提交或回滚很容易=28=] 和 工作区.
为什么Git需要设计Index/Stage？
图片
这是对即将提交的更改的预览。您可以逐步或一次性地在此专用 space 中构成未来的提交，检查其中的内容，并仅在您对其内容满意时才提交。
有些人几乎忽略了它的存在并且从不使用 add，依靠 -a 来盲目地添加所有内容，但这被认为是不好的做法，因为它会在未来引起麻烦，在在更复杂的情况下，对索引的理解 将 至关重要。
暂存的文件用作显示，提交者可以在其中看到他将要添加到该特定提交的更改。它还有助于输入 git commit -a，这是 @Romain 提到的一种不好的做法。
下面是另一个用例，
您对 a.txt 和 b.txt 进行了更改，但无论出于何种原因，都需要对这些文件执行两次单独的提交（可能将 a.txt 推送到不同的分支并将 b.txt 推送到不同的分支分支！）。想象一下要承担的工作！
拥有索引文件只是让开发人员的生活变得轻松，而不是盲目的设计决定。
Mercurial 证明 Git 的索引/暂存区不是必需的。 Mercurial 和 Git 同样强大（至少就存储修订而言），但在 Mercurial 中，工作树 是 暂存区/建议下一次提交。在Git中，工作树是无关紧要的，索引是暂存区/建议的下一次提交。
也就是说，Git 比 Mercurial 快得多。这种速度的很大一部分是 Git 保留其单独索引的结果（尽管很多也是由于 Mercurial 在 Python 而不是 C 中的实现）。所以索引的存在 Git 相当多 "go-fast"，如果你愿意的话。
虽然有些人觉得单独的暂存区只不过是一种烦恼，但其他人（正如您在其他答案中看到的那样）发现这个单独的暂存区非常方便。特别是，您可以暂存某些内容——将某个版本的文件从工作树复制到暂存区——然后进一步或以不同方式修改工作树文件，例如添加不在暂存区中的调试信息- 提交该文件的副本。使用 git add -p 和 git reset -p，您可以添加和删除特定修复程序，同时让调试部分 仅 存在于工作树中。
因此，这提供了拥有索引的两个动机：您可以有一个故意与您的工作树不同的暂存区域，并且 Git 运行得更快 因为 Git 的暂存区 已经适合提交 。 （Mercurial 未 准备好提交：工作树必须首先被按摩到适合提交的形式，无论哪种语言实现按摩或您抛出多少缓存在这个问题上，这里仍然会有一些计算工作。）
一旦您接受了 单独 暂存区的想法，这提供了第三个动机：现在您可以随时创建额外的暂存区，如果这对一些特定的目的。例如，这就是 git stash 的实现方式。 （它也涉及 git worktree add，尽管额外的工作树被添加为 对： 你会得到一个带有新索引的新工作树。如果有的话，那就是新的工作树应该 成为 新的索引，即 Mercurial 模型更好！）
下图是Git流程图，很奇怪为什么Git需要设计Index /Stage.
你知道 Repository 和 Workspace 之间的通信是本地的，Repository[ 之间的提交或回滚很容易=28=] 和 工作区.
为什么Git需要设计Index/Stage？
图片
这是对即将提交的更改的预览。您可以逐步或一次性地在此专用 space 中构成未来的提交，检查其中的内容，并仅在您对其内容满意时才提交。
有些人几乎忽略了它的存在并且从不使用 add，依靠 -a 来盲目地添加所有内容，但这被认为是不好的做法，因为它会在未来引起麻烦，在在更复杂的情况下，对索引的理解 将 至关重要。
暂存的文件用作显示，提交者可以在其中看到他将要添加到该特定提交的更改。它还有助于输入 git commit -a，这是 @Romain 提到的一种不好的做法。
下面是另一个用例，
您对 a.txt 和 b.txt 进行了更改，但无论出于何种原因，都需要对这些文件执行两次单独的提交（可能将 a.txt 推送到不同的分支并将 b.txt 推送到不同的分支分支！）。想象一下要承担的工作！
拥有索引文件只是让开发人员的生活变得轻松，而不是盲目的设计决定。
Mercurial 证明 Git 的索引/暂存区不是必需的。 Mercurial 和 Git 同样强大（至少就存储修订而言），但在 Mercurial 中，工作树 是 暂存区/建议下一次提交。在Git中，工作树是无关紧要的，索引是暂存区/建议的下一次提交。
也就是说，Git 比 Mercurial 快得多。这种速度的很大一部分是 Git 保留其单独索引的结果（尽管很多也是由于 Mercurial 在 Python 而不是 C 中的实现）。所以索引的存在 Git 相当多 "go-fast"，如果你愿意的话。
虽然有些人觉得单独的暂存区只不过是一种烦恼，但其他人（正如您在其他答案中看到的那样）发现这个单独的暂存区非常方便。特别是，您可以暂存某些内容——将某个版本的文件从工作树复制到暂存区——然后进一步或以不同方式修改工作树文件，例如添加不在暂存区中的调试信息- 提交该文件的副本。使用 git add -p 和 git reset -p，您可以添加和删除特定修复程序，同时让调试部分 仅 存在于工作树中。
因此，这提供了拥有索引的两个动机：您可以有一个故意与您的工作树不同的暂存区域，并且 Git 运行得更快 因为 Git 的暂存区 已经适合提交 。 （Mercurial 未 准备好提交：工作树必须首先被按摩到适合提交的形式，无论哪种语言实现按摩或您抛出多少缓存在这个问题上，这里仍然会有一些计算工作。）
一旦您接受了 单独 暂存区的想法，这提供了第三个动机：现在您可以随时创建额外的暂存区，如果这对一些特定的目的。例如，这就是 git stash 的实现方式。 （它也涉及 git worktree add，尽管额外的工作树被添加为 对： 你会得到一个带有新索引的新工作树。如果有的话，那就是新的工作树应该 成为 新的索引，即 Mercurial 模型更好！）