关于revert:git status显示修改,git checkout – < file>

git status shows modifications, git checkout — <file> doesn't remove them

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
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")


我在Windows上遇到了这个问题,但不准备调查使用config --global core.autocrlf false的后果,我也不准备放弃藏匿的其他私人分支机构和商品,从一个新的克隆开始。我只需要做点什么。现在。

这对我很有用,因为你让Git完全重写你的工作目录:

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

(注意,仅仅运行git reset --hard还不够好,在reset之前的文件上也没有一个普通的rm,正如对原始问题的评论中所建议的那样)


有多个问题可导致这种行为:

行尾规范化

我也遇到过这样的问题。归根结底是Git自动将CRLF转换为LF。这通常是由单个文件中的混合行结尾引起的。文件在索引中被规范化,但是当Git再次将其反规范化以将其与工作树中的文件进行比较时,结果是不同的。

但是如果你想解决这个问题,你应该禁用core.autocrlf,将所有行尾改为lf,然后再次启用它。或者您可以通过执行以下操作完全禁用它:

1
git config --global core.autocrlf false

您也可以考虑使用.gitattribute文件,而不是core.autocrlf。这样,您就可以确保使用repo的每个人都使用相同的规范化规则,防止混合行结尾进入存储库。

还可以考虑将core.safecrlf设置为warn,如果您希望Git在执行不可逆规范化时警告您。

Git手册页上说:

CRLF conversion bears a slight chance
of corrupting data. autocrlf=true will
convert CRLF to LF during commit and
LF to CRLF during checkout. A file
that contains a mixture of LF and CRLF
before the commit cannot be recreated
by git. For text files this is the
right thing to do: it corrects line
endings such that we have only LF line
endings in the repository. But for
binary files that are accidentally
classified as text the conversion can
corrupt data.

不区分大小写的文件系统

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

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


另一个可能适用于人的解决方案,因为没有一个文本选项适用于我:

  • .gitattributes的内容替换为一行:* binary。这就告诉Git将每个文件都当作二进制文件来处理,而这是它无法处理的。
  • 检查有问题的文件的消息是否已消失;如果没有,您可以使用cx1〔6〕将它们恢复到存储库版本。
  • git checkout -- .gitattributes.gitattributes文件恢复到初始状态
  • 检查文件是否仍未标记为已更改。

  • 对于未来有此问题的人:文件模式更改也可能有相同的症状。git config core.filemode false将修复它。


    这让我发疯了,尤其是如果没有任何在线解决方案,我就无法解决这个问题。我就是这样解决的。不能在这里取学分,因为这是同事的工作:)

    问题来源:我最初安装的Git在Windows上没有自动换行。这导致我对GLFW的初始承诺没有适当的行尾。

    Note: This is only a local solution. The next guy cloning the repo
    will still be stuck with this problem. A permanent solution can be
    found here:
    https://help.github.com/articles/dealing-with-line-endings/#re-normalizing-a-repository.

    设置:徐本图12.04GLFW项目的Git回购

    问题:无法重置glfw文件。不管我做了什么,它们总是显示为修改过的。

    解决了的:

    1
    2
    3
    4
    5
    6
    7
    edit .gitattributes

    Comment out the line:    # text=auto

    Save the file

    restore .gitattributes:   git checkout .gitattributes


    我有一个.bat文件有同样的问题(无法在未跟踪的文件中消除它)。Git签出——不起作用,这个页面上的任何建议也不起作用。唯一对我有用的就是:

    1
    git stash save --keep-index

    然后删除隐藏:

    1
    git stash drop


    有两次同样的问题!这两次我都藏了一些我做的修改,然后试图把它们放回去。无法弹出更改,因为我有很多文件被更改了--但没有!它们完全一样。

    我现在认为我已经尝试过上述所有的解决方案,但没有成功。在尝试之后

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

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

    当比较文件时,它说我已经删除了所有行,然后再次添加它们。

    有点烦人。我现在将避免在将来藏匿。

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


    我只能通过临时删除repo的.gitattributes文件(定义了* text=auto*.c text)来解决这个问题。

    删除之后,我运行了git status,修改就消失了。他们甚至没有回来。gitattributes被放回原处。


    尝试做一个

    git checkout -f

    这将清除当前有效的本地回购的所有变化。


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

    此外,一些程序(如Linux上的bash)确实要求.sh文件是LF终止的。

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

    例如,您可以有这样的.gitattributes:*文本=自动

    如果每个文件类型/扩展名在您的案例中确实很重要,那么您也可以对其进行更具体的描述。

    然后autocrlf可以在本地转换Windows程序的行尾。

    在一个混合的C/Y/C++/Java/Ruby/R,Windows/Linux项目下,这是一个很好的工作。到目前为止没有问题。


    我也有同样的症状,但是由不同的事情引起的。

    我不能:

    1
    2
    3
    git checkout app.js //did nothing
    git rm app.js //did nothing
    rm -rf app.js //did nothing

    即使在git rm --cached app.js它签名为已删除,在未跟踪的文件中,我可以看到app.js。但当我再次尝试rm -rf app.js和peform git status时,它仍然显示"未跟踪"中的文件。

    经过与同事的几次尝试,我们发现这是由咕噜声引起的!

    由于Grunt已打开,并且由于app.js是由其他几个js文件生成的,我们发现每次使用js文件(也就是这个app.js)操作后,都会再次生成app.js。


    这里有很多解决方案,在我想出自己的解决方案之前,我可能应该尝试一下。不管怎样,这里还有一个…

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

    不幸的是,这似乎导致了类似这里描述的问题:在DOS-2-Unix完成之前,一旦代码合并,文件将永远标记为已更改,无法恢复。

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

    以下是我所做的:

  • 在意识到我有这个问题之前,我首先做了一个合并,然后不得不中止这个合并——git reset --hard HEAD(我遇到了一个合并冲突。如何中止合并?)

  • 我在vim中打开了有问题的文件,并改为unix(:set ff=unix)。当然可以使用像dos2unix这样的工具。

  • 坚信的

  • 在中合并了master(master进行了DOS-2-unix更改)

    埃多克斯1〔14〕

  • 解决了冲突,文件又是DOS文件,所以在VIM中时,必须对:set ff=unix进行处理。(注意,我已经安装了https://github.com/itchyny/lightline.vim,它允许我查看vim状态行上的文件格式)

  • 坚信的。全部排序!

  • 如果克隆存储库并立即看到挂起的更改,则存储库处于不一致状态。请不要从.gitattributes文件中评论* text=auto。这是专门放在那里的,因为存储库的所有者希望所有文件以LF行尾一致的方式存储。

    正如汉卡所说,遵循https://help.github.com/articles/dealing-with-line-endings/上的说明是解决问题的方法。简单按钮:

    1
    2
    3
    4
    5
    6
    git clone git@host:repo-name
    git checkout -b normalize-line-endings
    git add .
    git commit -m"Normalize line endings"
    git push
    git push -u origin normalize-line-endings

    然后将分支合并(或拉取请求)到回购的所有者。


    我遇到的问题是Windows不关心文件名大小写,但Git关心。所以Git存储了一个文件的大小写版本,但只能签出一个。


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

    Git添加。

    git commit-m"随机提交"

    git reset--硬头~1


    对我来说,问题是在执行命令时打开了Visual Studio

    埃多克斯1〔2〕

    关闭Visual Studio后,该命令起作用,我终于可以从堆栈中应用我的工作。因此,检查所有可以更改代码的应用程序,例如sourcetree、smartgit、notepad、notepad++和其他编辑器。


    当repo的贡献者在Linux机器上工作时,或者具有cygwin和文件权限的Windows发生更改时,也会发生此问题。吉特只知道755和644。

    此问题的示例及其检查方法:

    1
    2
    3
    4
    5
    git diff styleguide/filename

    diff --git a/filename b/filename
    old mode 100644
    new mode 100755

    为了避免这种情况,您应该确保使用

    1
    git config --global core.filemode false

    我是这样解决的:

  • 复制所需正确代码的内容
  • 从磁盘中删除导致问题的文件(无法恢复的文件)。现在,您应该发现同一个文件的两个版本都标记为已删除。
  • 提交删除文件。
  • 用相同的名称重新创建文件并粘贴到步骤1中复制的正确代码中
  • 提交新文件的创建。
  • 这就是我的工作。


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

    1
    2
    git add -A
    git reset --hard


    我们公司也面临同样的情况。所有建议的方法都没有帮助我们。研究的结果揭示了这个问题。问题是在Git中有两个文件,它们的名称只在符号寄存器中有所不同。Unix系统将它们视为两个不同的文件,但Windows正变得疯狂。为了解决这个问题,我们删除了服务器上的一个文件。之后,在Windows上的本地存储库中帮助执行以下几个命令(按不同的顺序):

    1
    2
    3
    git reset --hard
    git pull origin
    git merge

    我以前碰到过这个问题。我目前正在开发雇主提供的Windows10计算机。今天,这个特定的Git行为是由我从我的"开发"分支创建一个新分支引起的。出于某种原因,在我切换回"开发"分支之后,一些看似随机的文件持续存在,并在"git状态"中显示为"已修改"。

    而且,在那个时候我不能签出另一个分支,所以我被困在了我的"开发"分支上。

    我就是这样做的:

    1
    $ git log

    我注意到,我今天早些时候从"开发"创建的新分支显示在第一条"提交"消息中,在"head->develop,origin/develop,origin/head,the-branch-i-created-early-today"结尾处引用。

    因为我并不真正需要它,所以我删除了它:

    1
    $ git branch -d The-branch-i-created-earlier-today

    更改的文件仍在显示,因此我做到了:

    1
    $ git stash

    这解决了我的问题:

    1
    2
    3
    4
    5
    $ git status
    On branch develop
    Your branch is up to date with 'origin/develop'.

    nothing to commit, working tree clean

    当然,$ git stash list会显示隐藏的更改,由于我的隐藏数量很少,也不需要任何隐藏,所以我删除了所有隐藏。

    注意:我还没有试着按照别人在我之前的建议做:

    1
    2
    $ git rm --cached -r .
    $ git reset --hard

    这也可能有效,下次遇到这个问题时我一定要试试。


    我通过编辑.git/config解决了这个问题,并添加了:

    1
    2
    3
    [branch"name_branch"]
        remote = origin
        merge = refs/heads/name_branch

    然后我去了.git/refs/heads/name_分支机构并将最后一个提交的OCx1〔5〕的ID