我已经阅读了 git 文档一段时间了，并意识到在很多命令中，当涉及到“工作目录”和“工作树”之间的区别时，文档是模棱两可的。我知道这里状态的变化，并且更常用的命令（如 add）也是一致的。但是对我昨天所做的文档的 grep 显示，许多命令仍未相应更新。
这让我想到了下一点，那么每个概念的精确定义是什么，因为它们似乎在配置和存储文档中可以互换使用？工作目录只是一个等待修复的过时错误吗？
上面的状态变化是否是为了解决混淆并表示状态是唯一的每个工作树，因为它的 HEAD？
如果是这种情况，那么 gc 每个工作树也是唯一的，还是在 fsck 之类的“数据库”上完成？与 stash 相同的想法，stash 是否关心它被称为什么工作树？
在一般的版本控制系统中（不仅仅是 Git），总是必须有一个工作的地方。这个地方使用的名称各不相同：工作树、工作树、工作目录等。总的来说，工作树或工作树或某些变体可能是最好的，因为“工作目录”似乎暗示了单一级别的“目录性” ”。
Git 的名称总是有点不一致，但使用“工作树”或“工作树”的举动相当稳定。git worktree从历史上看，当子命令在 Git 2.5 版中正式进入 Git时，这一点变得更加重要。
所以，具体来说：
[短语]工作目录[在文档
git stash中]只是一个等待修复的过时错误吗？
我会这么说，是的。
上面的状态变化是为了解决混淆并表示状态是唯一的每个工作树，因为它的 HEAD？
是的。但是请注意，它git status基于三个项目动态计算状态：（每个工作树HEAD有一个HEAD）、索引（每个工作树有一个索引）和工作树。
（令人困惑的是，任何命令都可以建立自己的临时索引并使用它。每个工作树的一个索引是该工作树的一个“真实”索引，除了由某个命令临时创建并设置为的任何临时索引$GIT_INDEX_FILE。）
如果是这种情况，那么 gc 每个工作树也是唯一的，还是在 fsck 之类的“数据库”上完成？
git gc在数据库上工作。但是，因为它删除了未引用的对象，所以这是一个特别复杂的情况：它必须查看每个索引和每个（可能是分离的）HEAD，这意味着它必须遍历所有工作树。
与 stash 相同的想法，stash 是否关心它被称为什么工作树？
git stash所做的是进行两次，有时甚至是三次提交。它从索引和工作树中生成它们，因此您在哪个工作树中确实很重要。（第三次提交，如果存在，则包含未跟踪的文件：未跟踪但未忽略，或未跟踪-包括-忽略。这些也来自当前的工作树。）
提交本身没有分支。相反，默认情况下，其中一个提交（定位其他提交的那个）存储在 中refs/stash，使用其 reflog 保留任何先前的refs/stash值。