git reset --hard之后没有暂停的更改

Question

标题说明了一切。

在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在我的全局.gitconfig中设置为false。这可能是某种相关的吗？

Answer 1

我遇到了同样的问题，它与.gitattributes文件有关。 但是，导致该问题的文件类型未在.gitattributes中指定。

我只需运行

即可解决问题

git rm .gitattributes
git add -A
git reset --hard

Answer 2

的分辨!!!

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

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

git rm --cached -r .

2）重写Git索引以获取所有新行结尾。

git reset --hard

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

Answer 3

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

$ git add .
$ git reset --hard

这将暂存所有更改，这将导致Git知道这些文件，然后重置它们。

如果这不起作用，您可以尝试存储和删除更改：

$ git stash
$ git stash drop

Answer 4

If you use Git for Windows, this is likely your issue

I've had the same problem and stash, hard reset, clean or even all of them was still leaving changes behind. What turned out to be the problem was the x file mode that was not set properly by git. This is a "known issue" with git for windows. The local changes show in gitk and git status as old mode 100755 new mode 100644, without any actual file differences.

The fix is to ignore the file mode:

git config core.filemode false

More info here

Answer 5

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

似乎是.gitattributes文件，包含：

*.sln        eol=crlf
*.vcproj     eol=crlf
*.vcxproj*   eol=crlf

使项目文件显示为未分级。我不知道为什么会这样，而且我真的希望有人知道git的方法会给我们一个很好的解释。

我的解决方法是删除这些文件，并在autocrlf = false的{​​{1}}下添加[core]。

这与前一个配置完全不同，因为它要求每个开发人员都有.git/config。我想找到一个更好的解决办法。

编辑：

我评论了这些有罪的线条，取消了它们的评论并且它起作用了。什么......我甚至都没有......！

Answer 6

可能的原因＃1 - 行结束标准化

可能发生这种情况的一种情况是，当有问题的文件被检入存储库而没有正确的行结尾配置（1）时，导致存储库中的文件具有错误的行结尾或混合行结尾。要确认，请确认git diff仅显示行结尾中的更改（默认情况下可能不会显示这些更改，请尝试git diff | cat -v将回车视为文字^M个字符。）

随后，某人可能添加了.gitattributes或修改了core.autocrlf设置以规范化行结尾（2）。基于.gitattributes或全局配置，Git已对您的工作副本应用了本地更改，这些更改应用了请求的行结束规范化。不幸的是，由于某种原因，git reset --hard不会撤消这些行规范化更改。

解决方案

重置本地行结尾的解决方法无法解决问题。每当git“看到”文件时，它都会尝试重新应用规范化，从而产生同样的问题。

最好的选择是让git通过规范化仓库中的所有行结尾以匹配.gitattributes来应用它想要的规范化，并提交这些更改 - 请参阅Trying to fix line-endings with git filter-branch, but having no luck。

如果你真的想尝试手动恢复文件的更改，那么最简单的解决方案似乎是擦除修改后的文件，然后告诉git恢复它们，尽管我注意到这个解决方案似乎并不一致100％的时间（警告：不要运行此项，如果您修改的文件有除行结尾以外的更改!!）：

    git status --porcelain | grep "^ M" | cut -c4- | xargs rm
    git checkout -- .

请注意，除非您在某个时刻对存储库中的行结尾进行规范化，否则您将继续遇到此问题。

可能的原因＃2 - 案例不敏感

第二个可能的原因是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不区分大小写，会覆盖fileA与/foo/Bar/fileA的内容，导致其被“修改”。

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

/foo/bar/fileA
/foo/bar/filea

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

对不区分大小写的文件系统的git应该真正检测到这种情况并显示一条有用的警告消息，但它目前没有（这可能会在将来发生变化 - 请参阅git.git邮件中的this discussion和相关的建议补丁列表）。

解决方案

解决方案是将git索引中的文件和Windows文件系统上的大小写对齐。这可以在Linux上完成，它将显示事物的真实状态，或者在Windows上使用非常有用的开源实用程序Git-Unite。 Git-Unite会将必要的大小写更改应用于git索引，然后可以将其提交给repo。

（1）最有可能是使用Windows的人，对该文件没有任何.gitattributes定义，并使用core.autocrlf false的默认全局设置（请参阅（2））。

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

Answer 7

另一个原因可能是不区分大小写的文件系统。如果您的仓库中的多个文件夹位于同一级别，其名称仅因大小写而异，则会受到此影响。使用其Web界面（例如GitHub或VSTS）浏览源存储库以确保。

有关详细信息：https://stackoverflow.com/a/2016426/67824

Answer 8

如果其他答案无效，请尝试添加文件，然后重置

$ git add -A
$ git reset --hard

就我而言，这对git跟踪的一堆空文件很有帮助。

Answer 9

检查.gitattributes。

在我的情况下，我有*.js text eol=lf，git选项core.autocrlf是true。

它让我了解git自动转换我的文件行结尾并阻止我修复它甚至git reset --hard HEAD没有做任何事情的情况。

我通过在*.js text eol=lf中对.gitattributes进行评论并在其之后取消注释来解决此问题。

看起来只是git magic。

Answer 10

运行 clean 命令：

# Remove all untracked files and directories. (`-f` is `force`, `-d` is `remove directories`)

git clean -fd

Answer 11

这些方法都不适用于我，唯一的解决方案是核对整个回购并重新克隆它。这包括存储，重置，添加然后重置，clrf设置，区分大小写等。叹气..

Answer 12

你可以stash离开你的更改，然后放下藏匿处：

git stash
git stash drop

Answer 13

我遇到了一个涉及.gitattributes的类似问题，但我的案例涉及GitHub的LFS。虽然这不完全是OP的场景，但我认为它提供了一个机会来说明.gitattributes文件的作用以及为什么它可以以“幻像”形式导致未经分级的更改。 ＃34;差异。

在我的情况下，一个文件已经在我的存储库中，就像从一开始就一样。在最近的一次提交中，我添加了一个新的git-lfs track规则，使用的是后见之明有点过于宽泛的模式，并最终匹配这个古老的文件。我知道我不想改变这个档案;我知道我没有更改文件，但现在它是在我的未经修改的更改中，并且该文件上的任何数量的检出或硬重置都无法修复它。为什么呢？

GitHub LFS扩展主要通过利用git通过.gitattributes文件提供访问权限的钩子来工作。通常，.gitattributes中的条目指定应如何处理匹配文件。在OP的案例中，它关注的是线路终点的正常化;在我的，是否让LFS处理文件存储。在任何一种情况下，git在计算git diff时看到的实际文件与您在检查文件时看到的文件不匹配。因此，如果您通过与其匹配的.gitattributes模式更改文件的处理方式，它将在状态报告中显示为未分级的更改，即使文件中确实没有更改。

所有这些，我的回答＆＃34;问题是，如果.gitattributes文件中的更改是您想要做的，那么您应该真正添加更改并继续。如果没有，那么修改.gitattributes以更好地代表您想要做的事情。

参考

1. GitHub LFS Specification - 很好地描述了他们如何挂钩clean和smudge函数调用用简单的文本文件替换git对象中的文件哈希。

2. gitattributes Documentation - 有关自定义git处理文档的方式的所有详细信息。

Answer 14

我认为git for Windows存在问题，git在结帐时随机写错了行结尾，唯一的解决方法是结帐其他分支并强制git忽略更改。然后检查你真正想要工作的分支。

git checkout master -f
git checkout <your branch>

请注意，这会丢弃您可能有意进行的任何更改，因此只有在结帐后立即遇到此问题时才会这样做。

编辑：我可能第一次真的很幸运。事实证明，在切换分支后我再次得到了一点。事实证明，更改分支后，文件git报告为已修改。 （显然是因为git并没有始终正确地将CRLF行应用于文件。）

我更新了Windows的最新git，希望问题不复存在。

Answer 15

类似的问题，虽然我肯定只是在表面上。无论如何，它可以帮助某人：我做了什么（FWIW，在SourceTree中）：隐藏未提交的文件，然后进行硬重置。

Answer 16

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

要解决这个问题，我让git知道svg文件应该被视为二进制而不是文本，方法是将以下行添加到.gitattributes

* .svg binary

Answer 17

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

我的解决方案相对简单。 我刚关闭了我的IDE（这里是Xcode）并关闭了我的命令行（这是我的Mac OS上的终端）并再次尝试它并且它有效。

然而，我始终无法找到导致问题的原因。

Answer 18

在类似情况下。由于许多程序员遭受了多年的折磨，他们能够将行尾的不同编码（。 asp 、. js，.css ...不是本质）填充到一个文件中。前段时间拒绝了.gitattributes。回购设置为autorclf = true和safecrlf = warn。

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

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

How to normalize working tree line endings in Git?的提示有所帮助

git add -u

Answer 19

我遇到的另一种可能性是，存储库中的一个软件包最终以分离的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文件夹中进入git status会产生以下结果：

HEAD detached at 7515f05

然后以下命令应解决该问题，其中master应该用您的本地分支替换：

git checkout master

然后您会收到一条消息，表明您的本地分支将在远程分支后面进行一定数量的提交。 git pull，您应该走出困境！

Answer 20

由于某种原因

git add .

没用，但是

$ git add -A

锻炼了！

Answer 21

尝试简单 git restore。

这就是git所说的并且正在工作