作为一个颠覆用户，git的索引是我所面临的最具挑战性的新概念，因为我考虑将其用于新项目。我读了许多人的评论，说他们没有使用索引（总是提交-a），但我认为可能有一个致命的原因，为什么我想要使用它。 （我与大约5个其他开发人员共享代码，在成熟的开发环境中工作，我们将代码合并到测试和稳定分支，并使用分支来实现实验性或重要的新功能。）
答案 0 :(得分：9)
您知道，索引允许您只提交要添加到存储库的部分文件。一般来说，我觉得这很有用。我可以对那些有效的文件进行更改，检查有效的部分，然后完成并检查其余部分。
真正的杀手示威;尝试使用交互式添加或补丁添加（使用git add -i或git add -p）。这将贯穿您的所有更改，并允许您有选择地将它们添加到索引中。这使您可以对文件进行大量更改，然后拆分提交。对于我们不时做出的'aha'修复非常有用。
看看this screencast，看看它是如何完成的。直到你自己尝试一下，你会发现它有多么有用。
答案 1 :(得分：6)
我欣赏Git索引的原因是为了进行本地更改。使用索引可以做的一件事与Subversion的“changelist”支持大致相同，只是它更方便。我经常只从几个可能被修改的文件中分出一个或两个文件来构造一个只包含那些文件的提交。使用Subversion，我必须考虑该更改列表的名称（即使它只是“工作”或“临时”），并在构建和提交更改列表期间重复键入该名称几次。
该索引还支持git add -p功能，我认为这是Git杀手功能之一。请参阅Ryan Tomayko的The Thing About Git，其中描述了Git如何解决“纠缠不清的工作副本问题”。您可以只修改已修改文件的部分，而无需在编辑器中使用Undo处理临时副本或播放技巧。
索引并不真正参与您与其他开发人员的交互。但是，它会对你与Git的互动方式产生重大影响。
答案 2 :(得分：3)
我发现索引非常有用，很少提交-a。
由于您在提交时并不总是推送到远程存储库，因此git用户通常会进行更小，更频繁的提交，并在完成“组”更改后推送到共享存储库。这使得能够灵活地在以后恢复或挑选单个提交。假设我做了3次更改，并使用subversion一次性提交它们，然后想要恢复其中一个更改..或者只将其中一个更改应用到另一个分支..这是一个非常繁琐的过程。使用git，您可以将已更改的每个文件添加到暂存区域，然后单独提交。显然，您需要确保提交内部一致，并确保每个更改集都是“原子”。
您可能还对不希望提交的版本控制下的文件进行本地更改，例如自定义配置文件（或其他内容）。登台区域允许您从提交的设置更改中排除该文件。
答案 3 :(得分：3)
我发现暂存变更非常有用，原因有三个。
答案 4 :(得分：2)
有些人已经提到过git add -p，但是如果你从未使用它，你可能不会欣赏它的实用性。假设您有以下源代码行，其中包含3个错误：
distance= rate * deltaT; /* compute tax rate */
（三个错误是：错误名称变量deltaT，'='之前的空白错误，以及无效的评论。）
您已经编辑过该文件，但是您想要为每个文件进行3次不同的提交，并提供相应的日志消息。使用git，它相当简单，因为添加--patch实际上允许你直接进入编辑器并编辑补丁。
答案 5 :(得分：1)
除了交互式分段之外，索引的另一个重要用法是在合并冲突期间：Git会对文件的三个版本进行分级，因此它知道文件没有准备就绪，所以手头有一个版本没有乱丢与冲突标记。第三方工具可以使用此处的索引来提供良好的合并界面。
这并不是说这个功能从根本上要求索引 - 我确信Mercurial在没有索引的情况下处理合并冲突 - 但是git接近它的方式对我来说似乎很好。
答案 6 :(得分：1)
我更愿意尽可能地忽略索引。
答案 7 :(得分：0)
如果你想确保每个提交都会构建并通过你的测试套件（1），那么尽可能忽略索引。
当您使用索引时（以非常重要的方式检查某些更改而不是其他更改）您正在检查您可能尚未构建或运行的代码状态测试套件。
当然，对于某些事情（例如某些文档的更改），这可能无关紧要，并且使用索引是完全安全的。但是，摆脱这样做的习惯是很好的，这种习惯是以错误的方式进行，并习惯以正确的方式做到这一点：
git stash隐藏不想要提交的所有内容。（1）：并非所有人都关心每个提交都是可构建的，有效的代码状态。
有些人这样做是因为这意味着任何有人检查的版本至少会构建和运行。这对于开源项目（有人可能随时克隆您的项目）非常重要，并且在分割时可以帮助找到引入错误的位置（您不需要浪费时间跳过非工作，测试用例失败）状态）。
如果你不关心每个提交是一个整体，代码的工作状态，那么这并不重要。