我想删除对我的工作副本的所有更改。 运行git状态显示已修改的文件。 我所做的一切似乎都无法消除这些修改。 例如:

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git status
# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   Rhino.Etl.Core/Enumerables/CachingEnumerable.cs
#       modified:   Rhino.Etl.Core/Pipelines/SingleThreadedPipelineExecuter.cs
#       modified:   Rhino.Etl.Tests/Rhino.Etl.Tests.csproj
#       modified:   Rhino.Etl.Tests/SingleThreadedPipelineExecuterTest.cs
#
no changes added to commit (use "git add" and/or "git commit -a")

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git checkout -- Rhino.Etl.Core/Enumerables/CachingEnumerable.cs

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git status
# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   Rhino.Etl.Core/Enumerables/CachingEnumerable.cs
#       modified:   Rhino.Etl.Core/Pipelines/SingleThreadedPipelineExecuter.cs
#       modified:   Rhino.Etl.Tests/Rhino.Etl.Tests.csproj
#       modified:   Rhino.Etl.Tests/SingleThreadedPipelineExecuterTest.cs
#
no changes added to commit (use "git add" and/or "git commit -a")

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git checkout `git ls-files -m`

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git status
# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   Rhino.Etl.Core/Enumerables/CachingEnumerable.cs
#       modified:   Rhino.Etl.Core/Pipelines/SingleThreadedPipelineExecuter.cs
#       modified:   Rhino.Etl.Tests/Rhino.Etl.Tests.csproj
#       modified:   Rhino.Etl.Tests/SingleThreadedPipelineExecuterTest.cs
#
no changes added to commit (use "git add" and/or "git commit -a")

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git reset --hard HEAD
HEAD is now at 6c857e7 boo libraries updated to 2.0.9.2 and rhino.dsl.dll updated.

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git status
# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   Rhino.Etl.Core/Enumerables/CachingEnumerable.cs
#       modified:   Rhino.Etl.Core/Pipelines/SingleThreadedPipelineExecuter.cs
#       modified:   Rhino.Etl.Tests/Rhino.Etl.Tests.csproj
#       modified:   Rhino.Etl.Tests/SingleThreadedPipelineExecuterTest.cs
#
no changes added to commit (use "git add" and/or "git commit -a")

当前回答

同样的问题出现了两次!这两次都是我做了一些更改,然后试图把它们放回去。不能弹出的变化,因为我有很多文件被改变-但他们不是!它们完全一样。

我现在认为我已经尝试了以上所有的解决方案,但都没有成功。在尝试了

git rm --cached -r .
git reset --hard

我现在几乎修改了存储库中的所有文件。

当对文件进行差分时,它会说我已经删除了所有行,然后重新添加它们。

有点令人不安。从今以后,我再也不偷东西了。

唯一的解决方案是克隆一个新的存储库并重新开始。(上次做的)

其他回答

我提交了所有的更改,然后在提交时执行并撤消。 这对我很有效

转到添加 。

git commit -m "随机提交"

git重置-硬头~1

有多种问题会导致这种行为:

行结束归一化

我也遇到过这种问题。归根结底是git自动将crlf转换为lf。这通常是由单个文件中混合的行结束符引起的。该文件在索引中得到了规范化,但是当git再次对其进行反规范化以与工作树中的文件进行区分时,结果是不同的。

但如果你想解决这个问题,你应该禁用core。将所有行结束改为lf,然后再次启用它。或者你可以通过以下方法完全禁用它:

git config --global core.autocrlf false

而不是核心。独裁,你也可以考虑使用.gitattributes文件。通过这种方式,您可以确保使用repo的每个人都使用相同的规范化规则,防止混合的行尾进入存储库。

还要考虑设置核心。如果您希望git在执行不可逆规范化时发出警告,则使用Safecrlf。

git的手册上写着:

CRLF转换有轻微的可能性 破坏数据。autocrlf = true将 在提交和期间将CRLF转换为LF 结帐时LF到CRLF。一个文件 它含有LF和CRLF的混合物 之前无法重新创建提交 git。对于文本文件,这是 正确的做法是:修正直线 这样我们就只有LF线 存储库中的结尾。但对于 二进制文件 分类为文本的转换可以 腐败的数据。

不区分大小写的文件系统

在不区分大小写的文件系统中,当存储库中有不同大小写的相同文件名时,git尝试签出两个文件名,但最终只有一个出现在文件系统中。当git尝试比较第二个文件时,它会将其与错误的文件进行比较。

解决方案要么是切换到一个不区分大小写的文件系统,但这在大多数情况下是不可行的,要么是将一个文件重命名并提交到另一个文件系统上。

这一页上的其他内容都不起作用。这最终对我有用。没有显示未跟踪或已提交的文件。

git add -A
git reset --hard

有一致的行尾是件好事。例如,它不会触发不必要的合并,尽管这是微不足道的。我曾经见过Visual Studio用混合行结尾创建文件。

还有一些程序,如bash(在linux上)确实要求.sh文件以LF终止。

为了确保发生这种情况,可以使用gitattributes。不管autcrlf的值是什么,它都在存储库级别上工作。

例如,你可以有这样的.gitattributes: *文本=汽车

如果对您的情况有影响,您还可以更具体地指定每个文件类型/扩展名。

然后,selff可以在本地转换Windows程序的行结束符。

在c# / c++ /Java/Ruby/R, Windows/Linux的混合项目中,这种方法运行良好。目前还没有问题。

这里有很多解决方案,也许我应该在提出自己的解决方案之前尝试其中一些。总之,这里还有一个…

我们的问题是,我们没有对结束行进行强制执行,并且存储库混合使用DOS / Unix。更糟糕的是,在这个位置上,它实际上是一个开源的回购,而我们已经分叉了。那些拥有操作系统存储库主要所有权的人决定将所有的结束行更改为Unix,并且提交包含一个.gitattributes来强制行结束。

不幸的是,这似乎会导致像这里描述的那样的问题,一旦合并DOS-2-Unix之前的代码,文件将永远被标记为已更改,无法恢复。

在我的研究过程中,我遇到了- https://help.github.com/articles/dealing-with-line-endings/ -如果我再次面临这个问题,我会首先尝试一下。


以下是我所做的:

I'd initially done a merge before realising I had this problem and had to abort that - git reset --hard HEAD (I ran into a merge conflict. How can I abort the merge?) I opened the files in question in VIM and changed to Unix (:set ff=unix). A tool like dos2unix could be used instead of course committed merged the master in (the master has the DOS-2-Unix changes) git checkout old-code-branch; git merge master Resolved conflicts and the files were DOS again so had to :set ff=unix when in VIM. (Note I have installed https://github.com/itchyny/lightline.vim which allowed me to see what the file format is on the VIM statusline) committed. All sorted!