Question

为什么“git add”和“git commit”之间存在暂存区？我理解这个概念，但是在实际提交之前没有看到将文件添加到临时区域的意义。为什么不跳过这一步？

Answer 1

一个主要原因是您不必提交整个工作目录。您可以将其中的一部分移动到索引并仅提交那些。

例如，您正在处理两个不同的事情，现在您的代码看起来像

//random code

//bug fix

//new feature

您可以只展示//bug fix行并提交，然后暂存//new feature行并提交。

现在，每个提交都有两个不同的提交。稍后在测试中你意识到new feature提交已经破坏了某些东西，你可以删除new feature提交，但不必重新提交bugfix

正如Dickon Reed在他的回答中指出的那样，你也获得了git commit的表现，现在只需要在提交中添加索引中的内容。它不需要搜索您的树来查找所有更改。

Answer 2

git commit不必检查树中的每个文件以查看是否已更改。在一棵可以节省大量时间的大树上。
通过暂存某些文件（或某些文件中的某些更改），您可以很好地控制您想要提交的内容以及您不想提交的内容。例如，如果你发现一个微不足道的错误，同时通过一个大的改变，你可以快速分阶段提交一行错误修复，而不会阻碍所有其他改变。

Answer 3

您可能不想只提交部分更改。如果您修复了某些内容，则只能提交修复的相关更改。

Answer 4

这是一个纯粹的PITA（以我的拙见）。很明显，大多数UI工具（实际上我所知道的，包括Eclipse的EGit，Mac XCode和GitHub客户端）都没有公开这个功能。

我理解部分提交的概念。您不希望提交文件系统上的所有内容。但是为它引入“舞台”的概念是一种矫枉过正的行为。

目前办理登机手续有4个阶段：

1. Your file system
2. The staging
3. your local repository
4. the remote upstream

UI前端到git不会暴露登台。它们向您展示了您所拥有的所有变化。您可以检查要提交的那些，并在一次操作中提交。

可能，这是一个植入细节，升级为UI概念。而不是：

commit( X, Y, Z)

你有：

add(X), add(Y), add(Z), commit()

Answer 5

我刚刚开始探索DVCS的奇妙世界，虽然我已经把我的灵魂卖给了git恶魔，但我仍然没有偏见。在暂存区域的想法有一些冗余，但你可以完全忽略暂存区域（我在使用github客户端时做了）。另一方面，它提供了更大的灵活性，所以我会说这是不显眼的冗余，有时可以帮助你一点。

我想到的是，有太多的术语命名它：缓存，临时区域，索引。显然，这个设计决策是作为类似概念的集合出现的，并且它有一些历史。我的第一次赌注被证明是合理的 - 我去了Bitkeeper网站并在那里找到了“分期”（他们用它进行按需分支）

现在我猜测，在Bitkeeper管理Linux源代码时，这个功能被滥用，而不是为几个开发人员创建按需分支，而是由一个开发人员使用。后来因为这个用例被证明是有用的，Git整合了“staging area”的轻量级版本，通过为“index”或“cache”提供用户界面可以方便地实现。