标题说明了一切。

在git reset --hard之后，git status给了我Changes not staged for commit:部分内的文件。

我也试过git reset .，git checkout -- .，git checkout-index -f -a，但没有用。

那么，我如何才能摆脱那些未经调整的变化呢？

这似乎只适用于Visual Studio项目文件。奇怪的。请参阅此粘贴：http://pastebin.com/efzwpn9z。这些文件的特殊之处在于.gitattributes中我有：

另外，在我的全球.gitconfig中，autocrlf设置为假。这有什么关系吗？

我也有同样的问题，它与.gitattributes文件有关。但是导致问题的文件类型没有在.gitattributes中指定。

我可以通过简单的跑步来解决这个问题

我使用以下STPE解决了这个问题

1)从Git索引中删除每个文件。

2)重写git索引以获取所有新行结尾。

解决方案是Git网站上描述的步骤的一部分https://help.github.com/articles/dealing-with-line-endings/

Git不会重置不在存储库中的文件。所以，你可以：

这将阶段化所有更改，这将导致Git了解这些文件，然后重置它们。

如果这不起作用，您可以尝试隐藏并删除更改：

我也遇到过同样的问题，藏起来，硬重置，清理，甚至所有的问题都没有改变。结果是问题出在了x文件模式上，它没有被git正确设置。这是Git for Windows的"已知问题"。本地更改以Gitk和Git状态显示为旧模式100755新模式100644，没有任何实际文件差异。

修复方法是忽略文件模式：

更多信息在这里

好吧，我已经解决了这个问题。

似乎.gitattributes文件包含：

使项目文件显示为未分页。我不知道这是为什么，我真的希望有人知道吉特的方式会给我们一个很好的解释。

我的解决办法是删除这些文件，并在.git/config中的[core]下添加autocrlf = false。

这与以前的配置并不完全相同，因为它要求每个开发人员都有autocrlf = false。我想找个更好的办法。

编辑：

我评论了那些指控的台词，对它们进行了注释，结果很管用。什么…我甚至不…！

可能发生这种情况的一种情况是，在没有正确配置行尾(1)的情况下，将相关文件签入存储库，从而导致存储库中的文件具有错误的行尾或混合的行尾。要确认，请验证git diff只显示行尾的更改(默认情况下，这些更改可能不可见，请尝试git diff | cat -v将回车视为文字^M字符)。

随后，可能有人添加了.gitattributes或修改了core.autocrlf设置以规范化行尾(2)。基于.gitattributes或global config，git已经将本地更改应用于您的工作副本，这些工作副本应用了请求的行结束规范化。不幸的是，由于某种原因，git reset --hard并没有撤消这些行标准化更改。

重置本地行尾的解决方法无法解决问题。每次Git"看到"该文件时，它都会尝试重新应用规范化，从而导致相同的问题。

最好的选择是让Git应用它想要的规范化，方法是规范化repo中的所有行尾以匹配.gitattributes，并提交这些更改——请参见尝试用Git过滤器分支修复行尾，但没有运气。

如果您真的想尝试手动恢复对文件的更改，那么最简单的解决方案似乎是删除修改过的文件，然后告诉Git恢复它们，尽管我注意到，这个解决方案在100%的时间内似乎无法始终如一地工作(警告：如果修改过的文件有行尾以外的更改，请不要运行这个程序！)！)

请注意，除非您在某个时刻规范化了存储库中的行尾，否则您将一直遇到这个问题。

第二个可能的原因是Windows或Mac OS/X上的大小写不敏感。例如，假设存储库中存在如下路径：

/foo/bar

现在Linux上有人将文件提交到/foo/bar中(可能是由于构建工具或创建该目录的东西)并推送。在Linux上，这实际上是两个单独的目录：

在Windows或Mac上检查此回购可能会导致修改后的fileA无法重置，因为每次重置时，Windows上的Git都会签出/foo/bar/fileA，然后因为Windows不区分大小写，所以用/foo/bar/fileA覆盖fileA的内容，从而导致它们被"修改"。

另一种情况可能是repo中存在的单个文件，当在不区分大小写的文件系统上签出时，这些文件会重叠。例如：

可能还有其他类似情况会导致此类问题。

不区分大小写的文件系统上的Git应该能够真正检测到这种情况并显示一条有用的警告消息，但它目前没有(这在将来可能会改变——请参阅git.git邮件列表上的讨论和相关的建议补丁)。

解决方案是使Git索引中的文件大小写和Windows文件系统中的文件大小写保持一致。这可以在Linux上完成，Linux将显示事物的真实状态，也可以在具有非常有用的开源实用程序GitUnite的Windows上完成。Git Unite将对Git索引应用必要的案例更改，然后将其提交给回购。

(1)这很可能是因为有人使用Windows，而没有对相关文件进行任何.gitattributes定义，并且使用core.autocrlf的默认全局设置，即false(请参见(2))。

(2)http://adaptivepatchwork.com/2012/03/01/mind-the-end-of-your-line/

另一个原因可能是不区分大小写的文件系统。如果同一级别的回购中有多个文件夹的名称只因大小写不同而不同，那么您将受到此影响。使用源存储库的Web界面(如github或vsts)浏览源存储库以确保。

更多信息：https://stackoverflow.com/a/2016426/67824

在我的例子中，当Git跟踪一堆空文件时，这有助于解决问题。

检查你的.gitattributes。

在我的例子中，我有*.js text eol=lf，而git选项core.autocrlf是true。

这让我陷入了这样的境地：Git自动转换我的文件行尾，阻止我修复它，甚至git reset --hard HEAD也没有做任何事情。

我在我的.gitattributes中用注释*.js text eol=lf来修正它，并在它之后取消注释。

看起来像是魔法。

运行清除命令：

你可以去掉你的零钱，然后扔掉这些东西：

这些方法对我来说都不起作用，唯一的解决办法就是核化整个repo并重新克隆它。这包括隐藏、重置、添加然后重置、CLRF设置、区分大小写等。

我遇到了一个类似的问题，也涉及到.gitattributes，但我的案件涉及到Github的LFS。虽然这并不完全是OP的场景，但我认为它提供了一个机会来说明.gitattributes文件的作用，以及为什么它可以导致"幻影"差异形式的未经调整的变化。

在我的例子中，一个文件已经在我的存储库中，就像从一开始的时候。在最近的一次提交中，我添加了一个新的git-lfs track规则，使用了一个事后看来过于宽泛的模式，最终与这个古老的文件匹配。我知道我不想更改这个文件；我知道我没有更改这个文件，但是现在它在我的未保存的更改中，并且该文件上没有多少签出或硬重置可以修复它。为什么？

Github LFS扩展主要通过利用git通过.gitattributes文件提供访问的钩子来工作。通常，.gitattributes中的条目指定如何处理匹配的文件。在OP的例子中，它涉及到规范化行尾；在我的例子中，它涉及到是否让LFS处理文件存储。在这两种情况下，当计算git diff时，git看到的实际文件与检查文件时看到的文件不匹配。因此，如果您更改了通过与文件匹配的.gitattributes模式处理文件的方式，那么它将在状态报告中显示为未分页的更改，即使文件中确实没有更改。

尽管如此，我对这个问题的"答案"是，如果.gitattributes文件中的更改是您想要做的，那么您应该添加这些更改并继续前进。如果没有，那么修改.gitattributes以更好地表示您要做的事情。

我遇到的另一个可能性是，存储库中的一个包最终以一个分离的头结束。如果这里的答案都不起作用，并且您遇到这样的Git状态消息，那么您可能会遇到同样的问题：

进入path/to/package文件夹，git status将产生以下结果：

然后，下面的命令应该解决这个问题，您的本地分支机构应该替换master：

您将收到一条消息，您的本地分支将是远程分支后面的一些提交量。你应该离开树林！

我认为Git for Windows存在一个问题，在这个问题中，Git在签出时随机写入错误的行尾，唯一的解决方法是签出其他分支并强制Git忽略更改。然后签出你真正想要处理的分支。

请注意，这将丢弃您可能有意进行的任何更改，因此只有在签出后立即出现此问题时才执行此操作。

编辑：我可能第一次真的很幸运。结果我在换了分支之后又被咬了。原来，在更改分支之后，Git报告的文件被修改了。(很明显，因为Git不总是正确地将CRLF行结束于文件。)

我更新到最新的Git for Windows，希望问题解决。

我也有同样的问题。我做了git reset --hard HEAD，但每次我做了git status，我都看到一些文件被修改了。

我的解决方案相对简单。我刚关闭了我的IDE(这里是Xcode)和命令行(这里是我的Mac操作系统上的终端)，然后再试了一次，结果成功了。

然而，我始终无法找到问题的根源。

类似的问题，尽管我确信只是表面上的问题。不管怎样，它可能对某些人有所帮助：我所做的(fwiw，在sourcetree中)：存储了未提交的文件，然后进行了硬重置。

正如其他答案所指出的，问题在于线路末端的自动校正。我在*.svg文件中遇到了这个问题。我在我的项目中使用SVG文件作为图标。

为了解决这个问题，我告诉Git应该将svg文件作为二进制文件而不是文本来处理，方法是将下面的行添加到.gitattributes中。

＊SVG二进制

在类似的情况下。由于多年来许多程序员的苦恼，他们能够填充不同的行尾编码(.asp，.js，.css…。不是本质)放在一个文件中。一段时间前拒绝了。Gittributes。repo-left-autorclf = true和docx1〔8〕的设置。

最后一个问题是，当从归档文件与不同的行尾进行同步时出现的。从存档复制后，在git状态下，许多文件都会用注释更改

The line will have its original line endings in your working directory.
warning: LF will be replaced by CRLF in ...

如何在Git中规范化工作树行尾的提示？帮助

git add -u