Git：我应该忽略索引还是有一个杀手级的应用程序？答案

【问题标题】：Git: Should I ignore the Index or is there a killer application for it?Git：我应该忽略索引还是有一个杀手级的应用程序？
【发布时间】：2009-12-03 00:07:19
【问题描述】：

作为一个颠覆用户，git 的索引是我在考虑将它用于新项目时面临的最具挑战性的新概念。我读过很多人的 cmets 说他们不使用索引（总是提交 -a），但我认为可能有一个杀手级的理由来解释我为什么要使用它。（我与大约 5 位其他开发人员共享代码，在成熟的开发环境中工作，我们合并代码以测试和稳定分支，并将分支用于实验性或重要的新功能。）

【问题讨论】：

+1：有趣的问题
我确信 Linus 一定在某个时候对这个主题发表过评论。 Git 真正吸引人的一件事是，添加每个功能都是为了支持内核黑客的一些实际需求（而不是完成功能比较清单），所以我相信 Linus 一定觉得它对管理很有用例如补丁的集成。
IMVHO 大部分时间你可以忽略索引...但是当你需要它时，它非常有用。
我想问题是你什么时候需要它。

标签： svn git

【解决方案1】：

当然，您知道索引只允许您提交要添加到存储库的部分文件。总的来说，出于这个原因，我发现它很有用。我可以对那些可以工作的文件进行更改，签入可以工作的部分，然后完成并签入其余部分。

对于一个真正的杀手示范；尝试使用交互式添加或补丁添加（使用git add -i 或git add -p）。这将贯穿您的所有更改，并允许您有选择地将它们添加到索引中。这使您可以对文件进行大量更改，然后拆分提交。对于我们不时进行的那些“啊哈”修复很有用。

看看this screencast 看看它是如何完成的。直到你自己尝试一下，你才会知道它有多大用处。

【讨论】：

酷截屏。我更喜欢add -p 而不是add -i — 界面不那么混乱。
我同意 -i 的界面令人困惑，但它将所有添加功能都集中在一个地方。一旦你习惯了那个菜单，它的作用就和 -p 一样。

【解决方案2】：

我欣赏 Git 索引的原因是用于暂存本地更改。您可以对索引做的一件事与 Subversion 的“更改列表”支持大致相同，只是它更方便。我经常从几个可能修改的文件中只暂存一个或两个文件，以构建一个只包含这些文件的提交。使用 Subversion，我必须为该更改列表想一个名称（即使它只是“工作”或“临时”），并在构建和提交更改列表期间重复输入该名称几次。

该索引还支持git add -p 功能，我认为这是 Git 的杀手级功能之一。请参阅 Ryan Tomayko 的 The Thing About Git，它描述了 Git 如何解决“纠结的工作副本问题”。您可以只暂存已修改文件的部分，而无需在编辑器中处理临时副本或玩弄“撤消”技巧。

索引并没有真正参与到您与其他开发人员的互动中。但是，它可能会对您与 Git 交互的方式产生重大影响。

【讨论】：

【解决方案3】：

我发现索引非常有用，而且很少提交 -a。

由于您在提交时并不总是推送到远程存储库，因此 git 用户通常会进行更小、更频繁的提交，并在完成“组”更改时推送到共享存储库。这为以后能够恢复或挑选单个提交提供了灵活性。假设我进行了 3 项更改，并使用 subversion 一次提交所有更改，然后想要还原其中一项更改.. 或仅将其中一项更改应用于另一个分支.. 这是一个非常繁琐的过程。使用 git，您可以将已更改的每个文件添加到暂存区域，然后分别提交。显然，您需要确保提交在内部是一致的，并确保每个更改集都是“原子的”。

您还可能对受版本控制的文件进行了本地更改，但您不想提交，例如自定义配置文件（或其他东西）。暂存区域允许您将该文件从已提交的更改集中排除。

【讨论】：

【解决方案4】：

出于三个原因，我发现分段更改非常有用。

我不会不小心提交太多更改，因为有一个额外的步骤来暂存文件。
在通过代码生成或模式替换对一堆文件进行一次更改后，我喜欢在提交之前逐步检查每个文件的差异。能够一个一个地暂存文件是为我的进度添加书签的好方法。
我可能正在处理一项功能，并在一些不相关的部分中发现过时的评论或错误的格式。我可以轻松地进行并提交这样的微小更改，让我的功能提交保持纯粹和专注。

【讨论】：

【解决方案5】：

很多人已经提到了 git add -p，但如果你从未使用过它，你可能不会欣赏它的实用性。假设您有以下包含 3 个错误的源代码行：

距离=速率* deltaT； /* 计算税率 */

（三个错误是：变量 deltaT 命名错误、'=' 之前的空白错误和无效注释。）

您已经编辑了该文件，但您想要进行 3 次不同的提交，并为每个提交提供适当的日志消息。使用 git，这相当简单，因为 add --patch 实际上允许您进入编辑器并直接编辑补丁。

【讨论】：

【解决方案6】：

除了交互式暂存之外，索引的另一个重要用途是在合并冲突期间：Git 暂存文件的三个版本，因此它知道文件尚未准备好，因此手头上有一个没有乱七八糟的版本带有冲突标记。第三方工具可以使用这里的索引来提供一个很好的合并界面。

这并不是说这个特性从根本上需要索引——我确信 Mercurial 在没有索引的情况下处理合并冲突——但 git 处理这个问题的方式对我来说似乎不错。

【讨论】：

【解决方案7】：

我更喜欢尽可能忽略索引。

【讨论】：

不反对，但也愿意解释为什么？
我并不经常想要提交一些更改，然后我通常想在不同的版本上提交这些更改。该索引在那里没有多大帮助。当我这样做时，我可以传递更多参数来提交。当我想自动化 [un] 提交时，暂存区也让我非常恼火。例如，我想将 git-hash 附加到我的构建中，以便我可以准确地识别构建。我不能在构建脚本中做这样的事情： git commit --allow-empty -am"Auto commit ..." build git reset --soft HEAD^ 由于暂存区，这必须复杂得多.
这条评论告诉我，也许你可以多读一点关于 git 的文章；例如，我建议使用 git-tag 来唯一标识构建。
Shhnap：你错过了我的意思。问题是工作树只有一个散列如果你提交。由于暂存区域，您不能简单地在脚本中提交/取消提交。如果您有哈希，则只能“git-tag”。现在关注？

【解决方案8】：

如果您想确保每次提交都能构建并通过您的测试套件 (1)，请尽可能忽略索引。

当您使用索引时（以非平凡的方式检查某些更改而不是其他更改）您正在检查您可能尚未构建或运行的代码状态测试套件在上。

当然，对于某些事情（例如更改某些文档），这可能无关紧要，使用索引是完全安全的。但是最好改掉容易出错的习惯，养成正确的习惯：

使用git stash 隐藏您不想想要提交的所有内容。
构建剩下的东西。
运行剩下的测试套件。
提交（全部）剩下的内容。
取消隐藏其他更改，必要时重复。

(1)：并不是每个人都关心每次提交都是可构建的工作状态的代码。

有些人这样做是因为这意味着有人签出的任何版本都至少会构建和运行。这对于开源项目（有人可能随时克隆您的项目）很重要，并且有助于在平分查找引入错误的位置时（您无需浪费时间跳过不工作的测试用例失败）州）。

如果您不关心每个提交是一个完整的代码工作状态，那么这并不重要。

【讨论】：

这就是git stash save --keep-index 的用途：能够测试（部分）分阶段的更改。
不能让每个提交完美运行的另一个原因是，在本地存储库中工作时，您希望提交小的更改，但是您可以使用 git rebase 将所有更改捆绑为一个原子提交发布到面向公众的存储库。