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