导入特定的.scss文件会破坏Git吗？

Question

您是否曾对文件进行过更改，导致git无法查看相应的更改？我今天遇到了这种奇怪的git行为。考虑一个文件main.scss，它是@imports .scss partials。日常场景，100％简单，永远，对吗？没问题。直到今天！

当我尝试使用路径“layout / sidebars / header”（指向相应的和现存的/layout/sidebars/header.scss文件）导入文件时，我观察到git中的奇怪/好奇/麻烦的行为。

添加该行后，git status会生成一个干净的状态，但是没有响应。即触摸新文件未注册任何更改。这种行为在下面的图像中举例说明，我希望它可以证明令人满意的表现出好奇的本质：

当我尝试将文件移动到一个名为“test.scss”的新文件，甚至是“test.test”（对于.gitignore怀疑论者）时，我没有得到一个很好的机会来提交新添加的文件，因为我期望。

Git已经停止根据代码中的这一行干净地跟踪文件，这是一个灾难的秘诀 - 因为人们可以成功地在他们自己的机器上构建，并且，一个可能出于某种不负责任的习惯会犯错误使用“ git add --all“，假设包含的文件是在那个提交中暂存的。如果该开发人员应该过快地摆脱习惯或使用其他一些管道命令，则问题已经到达存储库。

什么会导致这个？没有人喜欢在提交中破坏代码......但这是我第一次看到文件中的代码破坏了我的Git正确跟踪文件的能力？

我有点认为Git对文件的内容是不可知的，只是处理位模式和字节......所以包含文件会破坏Git的想法对我来说很奇怪。

任何有关此的见解或理论都非常感谢。

Answer 1

您跑了（如第二张图片中所示）：

mv main.scss test.scss

这改变了你的工作树，但不是你的索引.1当然，你当前或HEAD提交没有改变。

由于git status运行两个单独的git diffs（或多或少），这就是git status对此的看法：

1. 比较HEAD与index：没有任何改变。 因此，由于没有任何不同，因此尚未提交任何内容。
2. 比较索引与工作树。嗯，文件main.scss在索引中，但不在工作树中。它一定已被删除！ 由于工作树文件消失了，您最终必须删除main.scss。但是，由于您尚未要求Git将其从索引中删除，因此它将继续处于下一次提交中。因此，此删除尚未提交。您当然可以要求从此处的任何时候进行提交。

目前尚不清楚你的索引中是否有一个名为test.scss的文件。如果没有，那么刚出现在工作树中的新test.scss就是一个未跟踪的文件。它可能会也可能不会被忽略 - 如果不被忽视，git status会抱怨它，说它没有被攻击。如果它既没有被攻击也被忽略，那么git status就会对它保持沉默。忽略规则可以从偷偷摸摸的位置引入，所以使用git check-ignore -v在这里找到更多。

请注意，如果您使用git mv而不是普通的mv，Git将同时重命名工作树中的文件并重命名索引中的文件。然后，您的索引中将没有main.scss（因此它将被安排在下次提交时被删除），并且在索引和工作树中都将包含test.scss。

因为git status的git diff操作重命名检测，Git会将旧的main.scss与新的test.scss进行比较，发现它是相同的，并说你重命名了该文件。 （事实上​​，下一个提交只会缺少main.scss并且有test.scss-但是其他比较也会检测重命名，并将其报告为一个，前提是您要求Git检测重命名。）

---

1记住索引 - 也称为暂存区域或有时是缓存，具体取决于谁在进行调用 - 是您构建下一个提交的位置。它开始匹配你通过运行git checkout branch签出的提交：也就是说，它有一个每个文件的副本，采用Git使用的特殊Git格式，就像HEAD提交一样。

索引中的副本与HEAD提交中的副本之间的主要区别在于索引中的副本可以被修改或完全删除;并且可以将尚未包含在索引中的文件添加到其中。由于下次提交是在运行git commit时由索引中的任何内容构建的，因此建立新索引是你的工作。但由于索引中的文件采用这种特殊的，压缩的，仅Git格式，因此Git会将这些文件复制到您的工作树中，您可以在其中处理它们。使用git add path将文件复制回索引，覆盖之前的版本 - 或者如果之前没有，则在索引中创建该文件。

2要查看索引中的所有内容，请使用git ls-files --stage。但这非常冗长。通常，根据什么不同来查看索引会更有趣，这就是git status将HEAD-vs-index与index-vs-work-tree区分开来的原因。

Answer 2

在父.git模块中，来自master的一个特别邪恶的合并最终被证明负责在.gitignore中包含我的工作目录（git submodule）。因此，我创建的任何文件从未提供给git status不包括在舞台上。

正如@Torek指出的那样，调整与索引的反应是恰当的......这个只是欺骗性的，因为我无法在我的工作git存储库中找到相应的.gitignore规则。

挖深，但不要忘记搜索更高。