之后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 我有：
*.sln eol=crlf
*.vcproj eol=crlf
*.vcxproj* eol=crlf
此外，autocrlf在我的 global 中设置为 false .gitconfig。这可能有点相关吗？
我有同样的问题，它与.gitattributes文件有关。但是，导致问题的文件类型未在.gitattributes.
我能够通过简单地运行来解决这个问题
git rm .gitattributes
git add -A
git reset --hard
我已经使用以下步骤解决了这个问题
从 Git 的索引中删除所有文件。
git rm --cached -r .
重写 Git 索引以获取所有新的行尾。
git reset --hard
解决方案是配置 Git 以处理行尾中描述的步骤的一部分
Git 不会重置不在存储库中的文件。这样你就可以：
$ git add .
$ git reset --hard
这将暂存所有更改，这将导致 Git 知道这些文件，然后重置它们。
如果这不起作用，您可以尝试存储并删除您的更改：
$ git stash
$ git stash drop
我遇到了同样的问题，并且存储、硬重置、清理甚至所有这些问题都仍然留下了更改。原来的问题是 git 没有正确设置 x 文件模式。这是 git for windows 的“已知问题”。本地更改在 gitk 和 git status 中显示为旧模式 100755 新模式 100644，没有任何实际文件差异。
解决方法是忽略文件模式：
git config core.filemode false
好的，我已经解决了这个问题。
该.gitattributes文件似乎包含：
*.sln eol=crlf
*.vcproj eol=crlf
*.vcxproj* eol=crlf
使项目文件显示为未暂存。我不知道为什么会这样，我真的希望知道 git 方式的人能给我们一个很好的解释。
我的解决方法是删除这些文件，并autocrlf = false在[core]..git/config
这与之前的配置并不完全相同，因为它要求每个开发人员都拥有autocrlf = false. 我想找到更好的解决方法。
编辑：
我评论了有罪的行，取消了评论，它起作用了。什么……我什至没有……！
可能发生这种情况的一种情况是，当有问题的文件在没有正确配置行尾 (1) 的情况下签入存储库时，导致存储库中的文件具有不正确的行尾或混合行尾。要确认，请确认git diff仅显示行尾的更改（默认情况下这些可能不可见，请尝试git diff | cat -v将回车视为文字^M字符）。
随后，有人可能添加.gitattributes或修改了core.autocrlf设置以规范行尾 (2)。基于.gitattributes或全局配置，Git 已将本地更改应用于您的工作副本，这些更改应用了请求的行尾规范化。不幸的是，由于某种原因git reset --hard并没有撤消这些行规范化更改。
重置本地行结尾的解决方法不能解决问题。每次git“看到”文件时，它都会尝试重新应用规范化，导致同样的问题。
最好的选择是让 git 应用它想要的规范化，方法是规范化 repo 中的所有行结尾以匹配.gitattributes，并提交这些更改——请参阅Trying to fix line-endings with git filter-branch，但没有运气。
如果您真的想尝试手动还原对文件的更改，那么最简单的解决方案似乎是删除修改后的文件，然后告诉 git 恢复它们，尽管我注意到这个解决方案似乎并不能始终 100%时间（警告：如果您修改的文件有除行尾以外的更改！！）：
git status --porcelain | grep "^ M" | cut -c4- | xargs rm
git checkout -- .
请注意，除非您在某个时候对存储库中的行尾进行规范化，否则您将继续遇到此问题。
第二个可能的原因是 Windows 或 Mac OS/X 上不区分大小写。例如，假设存储库中存在如下路径：
/foo/bar
现在 Linux 上的某个人将文件提交到/foo/Bar（可能是由于构建工具或创建该目录的东西）并推送。在 Linux 上，这实际上是两个单独的目录：
/foo/bar/fileA
/foo/Bar/fileA
在 Windows 或 Mac 上签出此 repo 可能会导致修改后fileA无法重置，因为每次重置时，Windows 上的 git 都会签出/foo/bar/fileA，然后由于 Windows 不区分大小写，会覆盖fileAwith的内容/foo/Bar/fileA，导致它们被“修改”。
另一种情况可能是存储库中存在的单个文件，当在不区分大小写的文件系统上签出时，这些文件会重叠。例如：
/foo/bar/fileA
/foo/bar/filea
可能还有其他类似情况可能导致此类问题。
不区分大小写的文件系统上的 git 应该真正检测到这种情况并显示有用的警告消息，但它目前没有（这可能会在未来发生变化——请参阅git.git 邮件列表上的讨论和相关建议补丁）。
解决方案是将 git 索引中的文件大小写和 Windows 文件系统上的大小写对齐。这可以在 Linux 上完成，这将显示事物的真实状态，或者在 Windows 上使用非常有用的开源实用程序Git-Unite完成。Git-Unite 将对 git 索引应用必要的案例更改，然后可以将其提交到 repo。
(1) 这很可能是使用 Windows 的人，没有对相关文件进行任何定义，并且使用的是.gitattributes默认全局设置（参见 (2)）。core.autocrlffalse
(2) http://adaptivepatchwork.com/2012/03/01/mind-the-end-of-your-line/
$ git add -A
$ git reset --hard
就我而言，当 git 正在跟踪一堆空文件时，这会有所帮助。
造成这种情况的另一个原因可能是不区分大小写的文件系统。如果您在同一级别的存储库中有多个文件夹，其名称仅因大小写而异，您将受到打击。使用其 Web 界面（例如 GitHub 或 VSTS）浏览源存储库以确保。
您可以stash取消更改，然后删除存储：
git stash
git stash drop
运行清理命令：
# Remove all untracked files and directories. (`-f` is `force`, `-d` is `remove directories`)
git clean -fd
这些方法都不适合我，唯一的解决方案是核对整个 repo 并重新克隆它。这包括存储，重置，添加然后重置，clrf设置，区分大小写等。叹息..
检查您的.gitattributes.
在我的情况下，我有*.js text eol=lf它并且 git 选项core.autocrlf是true.
当 git 自动转换我的文件行结尾并阻止我修复它甚至git reset --hard HEAD没有做任何事情时，它让我陷入了这种情况。
*.js text eol=lf我通过在我的评论中修复它并在.gitattributes它之后取消评论它。
看起来它只是 git 魔法。
我相信 git for Windows 存在一个问题，其中 git 在结帐时随机写入错误的行尾，唯一的解决方法是结帐其他一些分支并强制 git 忽略更改。然后检查你真正想要工作的分支。
git checkout master -f
git checkout <your branch>
请注意，这将丢弃您可能有意进行的任何更改，因此仅当您在结帐后立即遇到此问题时才执行此操作。
编辑：我第一次可能真的很幸运。事实证明，我在切换分支后又被咬了。事实证明，在更改分支更改后，git 报告的文件已修改。（显然是因为 git 并没有始终如一地将 CRLF 行正确地应用于文件。）
我更新到最新的 Windows git 并希望问题消失。
我也遇到了一个类似的问题.gitattributes，但我的案例涉及 GitHub 的 LFS。虽然这不完全是 OP 的场景，但我认为它提供了一个机会来说明.gitattributes文件的作用以及为什么它会导致以“幻象”差异形式出现的未分级更改。
就我而言，一个文件已经在我的存储库中，就像从一开始一样。在最近的一次提交中，我添加了一个新git-lfs track规则，使用一种事后看来有点过于宽泛的模式，并最终匹配了这个古老的文件。我知道我不想更改此文件；我知道我没有更改文件，但现在它在我的未分阶段更改中，并且对该文件的任何签出或硬重置都无法修复它。为什么？
GitHub LFS 扩展主要通过利用git提供通过.gitattributes文件访问的挂钩来工作。通常，条目中的条目.gitattributes指定应如何处理匹配文件。在 OP 的情况下，它与规范化行尾有关；在我看来，是是否让 LFS 处理文件存储。在任何一种情况下，git计算 a 时看到的实际文件git diff都与检查文件时看到的文件不匹配。因此，如果您通过匹配文件的模式更改文件的处理.gitattributes方式，它将在状态报告中显示为未暂存的更改，即使文件中确实没有更改。
话虽如此，我对这个问题的“回答”是，如果.gitattributes文件更改是您想要做的事情，那么您应该只添加更改并继续前进。如果不是，则修改.gitattributes以更好地代表您想要做的事情。
GitHub LFS 规范- 很好地描述了它们如何挂钩clean和smudge函数调用，以git使用带有哈希的简单文本文件替换对象中的文件。
gitattributes 文档- 有关可用于自定义git文档处理方式的所有详细信息。
我有同样的问题。我做了git reset --hard HEAD，但每次git status我都看到一些文件被修改。
我的解决方案相对简单。我刚刚关闭了我的 IDE（这里是 Xcode）并关闭了我的命令行（这里是我的 Mac OS 上的终端）并再次尝试它并且它工作了。
然而，我始终无法找到问题的根源。
尝试简单地 git restore 。
这就是 git 所说的并且它正在工作
在类似的情况下。由于许多程序员多年的折磨，他们能够将行尾的不同编码（.asp、.js、.css ...不是本质）填充到一个文件中。前段时间拒绝了.gitattributes。repo leftautorclf = true和safecrlf = warn.
最后一个问题是从具有不同行尾的存档同步时出现的。从存档复制后，在 git status 中，许多文件都随注释更改
The line will have its original line endings in your working directory.
warning: LF will be replaced by CRLF in ...
如何在 Git 中规范化工作树行结尾的提示？帮助
git add -u
我遇到的另一种可能性是存储库中的一个包最终带有一个分离的 HEAD。如果这里的答案都没有帮助，并且您遇到这样的 git status 消息，您可能会遇到同样的问题：
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: path/to/package (new commits)
进入path/to/package文件夹 agit status应该会产生以下结果：
HEAD detached at 7515f05
然后下面的命令应该解决这个问题，master应该用你的本地分支替换：
git checkout master
您会收到一条消息，表明您的本地分支将在远程分支后面进行一些提交。git pull你应该走出困境！
类似的问题，虽然我确定只是表面上。无论如何，它可能对某人有所帮助：我做了什么（FWIW，在 SourceTree 中）：隐藏了未提交的文件，然后进行了硬重置。
正如其他答案所指出的那样，问题是由于线端自动更正。我在 *.svg 文件中遇到了这个问题。我在项目中使用 svg 文件作为图标。
为了解决这个问题，我让 git 知道 svg 文件应该被视为二进制而不是文本，方法是将下面的行添加到 .gitattributes
*.svg 二进制
由于某些原因
git add .
没用，但是
$ git add -A
解决了！