我发现有两个问题（由同一个用户询问）是否可以禁用暂存区域
没有一个答案真正回答了这个问题。
它们都有些味道你应该学会爱上演区
使用commit -a代替
但实际答案是什么？我可以设置一个git选项，以便尝试将更改部分移动到暂存区域失败吗？我猜答案是“不”，因为如果是“是”，有人会在上述问题之一中提到它。
（对于上下文，我使用commit --patch提交，我认为不需要暂存区域。）
（编辑：我想知道如何禁用暂存区域，因为我希望我经验较少的协作者能够以工具强制的方式避免与此功能交互.Git已经让他们感到困惑了。区域是另外一种不必要的并发症。）
答案 0 :(得分：4)
不，这是不可能的。许多人已经做了各种尝试来隐藏或以其他方式伪装Git的索引又名缓存又名临时区域，并且它们都失败了一个简单的原因：Git实际上，从 中提取新的提交 ，无论索引/登台区域是什么。
这有几个后果，其中一些立即all up in your grill，其中一些后来会打到你，包括：
工作树的内容与Git无关，除非是将文件存储到索引中的地方。您可以使用git commit -a来解决此问题，但不是完全可以解决此问题，其效果与在运行git add -u之前运行git commit非常相似。
当且仅当索引中存在文件时，跟踪文件。如果不注意索引的存在，即使您主要使用git commit -a处理它，也无法解释文件的跟踪，未跟踪和未跟踪以及未跟踪和忽略的状态。
git status命令运行两个比较：一个从HEAD提交到索引，一个从索引到工作树。解释其输出的唯一方法是承认索引的存在。
最终，如果选择这样做，它就是使用git add -p和其他面向补丁的操作（checkout -p和reset -p）存储部分更改的索引。当然，你可以完全避免这些;然后你永远不会看到索引的这个方面。
在合并操作期间 - 我想称之为动词的合并 - 遇到冲突，冲突的状态记录在索引中。 Git将具有冲突的文件的所有三个副本放入索引中。索引中的每个文件实际上都有四个分段插槽。此时，基本版本进入插槽1，HEAD或本地或--ours版本进入插槽2，远程或其他或--theirs版本进入插槽3。冲突实际上意味着做你自己的合并工作，然后将结果复制到正常的staging-slot零，擦除三个更高编号的staging条目。
Mercurial，与Git非常相似，没有索引/临时区域。这证明了概念是可能的。但是，Mercurial实现这一点的方式是它将工作树视为建议的新提交，而不是具有建议的新提交的单独索引对象。 Mercurial然后有一个名为 manifest 的第二个单独对象，用于确定跟踪哪些文件。冲突期间的合并状态存储在第三个位置（ dircache ）。在某种程度上，这实际上变得更加复杂，尽管它使得使用Mercurial的常见情况变得更加简单和用户友好。
为了让Git像Mercurial一样工作，你需要包装每个Git操作：隐藏整个用户界面和用户的实现，并使用一些辅助状态来跟踪索引状态的原因。从本质上讲，您需要创建自己的清单和dircache来记住要复制到索引中和从索引中复制的文件，以便使工作树看起来像是提议的提交。您需要自己的状态包装器，甚至可能希望始终以分离的HEAD模式运行（我没有充分考虑过极端情况，例如，hg histedit等效于此处。）