为什么吉特会这样?访问同一存储库的操作系统和虚拟机之间不一致

Git实际上没有“未提交文件”的概念。它所拥有的是 指数 工作树 .

提交:

• 提交是永久的(主要是 key-value store 为什么? 你做出了承诺。

  任何提交的“真名”都是它的哈希ID。Git使用哈希ID作为键值存储区中的键来检索提交。每个提交还包含其前置任务或 起源 提交(或者,对于合并提交,两个或多个父哈希ID这就是使它们成为“合并提交”的原因)。

一次承诺总是 现在的 承诺。这就是您选择的提交(通过 git checkout )一起工作。因为提交是只读的,所以 不能 更改此提交。你能做的是,在某个时刻,做一个 新的 成为 当前的提交,这就是为什么你总是可以得到你所提交的每个文件:提交是永久的(大部分)和只读的(完全)并且记住他们的父母。

提取自 每次提交后才能使用它们。因此,Git还具有:

• 不应该

  由于工作树中的文件以本机格式存储,并且被其他程序使用,Git提供了 修改 文件特别是行结尾和权限位,它们是在进入工作树的过程中从提交中产生的,并且是在从工作树进入提交时产生的。但还有一个关键问题,这就是最头疼的地方。

• 这个 . 这个项目位于 之间

索引将所有文件存储为其特殊的Git-only格式。它 开始 包含提交时的文件。提交文件副本和索引副本的关键区别在于 大批更换 ,使用 git add

当你做一个 新的 提交时,Git只使用当时索引中的任何内容。所有的文件都已经存在了,都是以Git格式预先打包的。这使得承诺变得非常迅速。

这也意味着从只使用Git的格式转换为“此计算机可用”的格式,反之亦然,在 (它将文件从Git改为useable)和 git添加 (更改为只能使用Git)。

跟踪 (索引!)使用操作系统特定信息的工作树。通过操作系统找到的特定于操作系统的信息 关于

如果共享工作树和索引 .git 跨机器的文件,发生的情况是索引本身变得无用,因为存储了特定于操作系统的工作树数据 索引是针对VM或主机的,但决不能同时针对两者。

当索引正确并且正确描述了工作树时, git status 快速准确。如果不是的话,两个不同的是,它必须运行查看我对你链接的问题的回答,我的回答不能像你这样高效。如果使用任何类型的文件转换,则必须重新运行它们,或者假定它们已更改了文件。

这一切的目标是: 工作,却成了可怕的经历。您发现的文件名案例折叠问题是另一个噩梦冰山的一角(不是通过不共享存储库直接解决的,但至少 以这种方式解决)。

^1个 去除 一个承诺,只要你还把它所有的孩子和他们的孩子都带走等等。也就是说,消除一个犯罪需要一种犯罪线种族灭绝。这样做通常是个坏主意,如果你要这样做,你通常必须复制整个儿童链,但有时这是个好主意,事实上这就是 git rebase 是内部的。

请注意 git commit --amend 更改提交。相反,它只是通过创建一个新的替换链式提交结尾(使用当前提交的父级作为新提交的父级),将现有链式提交结尾推到一边(从而最终杀死并移除)。