git status顯示修改，git checkout - <file>不會刪除它們

Question

我想刪除我的工作副本的所有更改。
運行git status顯示修改的文件。
我沒有做任何事似乎刪除這些修改。
例如爲：

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") 

Answer 1

有多種問題可能導致此行爲：

行結束規範化

我有這類問題了。它歸結爲自動將crlf轉換爲lf的git。這通常是由單個文件中的混合行尾引起的。該文件在索引中得到了規範化，但是當git再次非規範化它以將其與工作樹中的文件進行比較時，結果是不同的。

但是，如果你想解決這個問題，你應該禁用core.autocrlf，改變所有行結束LF，然後重新啓用它。或者你也可以這樣做完全禁用它：

git config --global core.autocrlf false 

而不是core.autocrlf，你也可以考慮使用.gitattribute文件。這樣，您可以確保使用repo的每個人都使用相同的規範化規則，防止混合行結束進入存儲庫。

還考慮設置core.safecrlf警告你是否希望git在執行不可逆規範化時發出警告。

manpages這樣說的混帳：

CRLF轉換承載破壞數據的輕微的機會 。 autocrlf = true將 在提交期間將CRLF轉換爲LF，並在結賬期間將LF轉換爲CRLF。一個文件 包含混合的LF和CRLF 之前提交不能被git重新創建 。對於文本文件，這是 正確的做法：它糾正行 結尾，使得我們在存儲庫中只有LF行 結尾。但對於 二進制文件，意外 歸類爲文本轉換可以 損壞的數據。

不區分大小寫的文件系統

在不區分大小寫的文件系統，當具有不同外殼中的相同的文件名是在存儲庫中，GIT中試圖檢出兩者，但只有一個文件系統上的最終。當git試圖比較第二個時，它會將它與錯誤的文件進行比較。

該解決方案要麼切換到非大小寫不敏感的文件系統，但在大多數情況下這是不可行或重命名並提交另一個文件系統上的文件之一。

Answer 2

一致的行結束是件好事。例如，它不會觸發不必要的合併，雖然微不足道。我已經看到Visual Studio創建混合行尾的文件。

另外一些程序，如bash（在Linux上），確實需要.sh文件是LF終止。

要確保發生這種情況，您可以使用gitattributes。無論autcrlf的值是什麼，它都可以在存儲庫級別上運行。

例如，你可以有這樣的.gitattributes： *文字=自動

您也可以按文件類型/擴展更具體的，如果它在你的情況下，事情並沒有。

然後autocrlf可以在本地爲Windows程序轉換行結束符。

在一個混合的C＃/ C++/Java/Ruby/R，Windows/Linux項目上，這很好。目前沒有問題。

Answer 3

對於將來有這個問題的人：具有文件模式更改也可能具有相同的症狀。 git config core.filemode false將解決它。

Answer 4

這一直讓我發瘋，特別是如果沒有網上找到的任何解決方案，我都無法解決這個問題。這是我如何解決它。因爲這是一位同事的工作，所以不能在這裏學分:)

問題的根源：我的初始安裝git沒有在Windows上進行自動換行。這導致我最初承諾GLFW沒有適當的線路結束。

注意：這只是本地解決方案。克隆repo 的下一個人仍然會遇到這個問題。永久解決方案可以是 在此處找到： https://help.github.com/articles/dealing-with-line-endings/#re-normalizing-a-repository。

設置： 是Xubuntu 12.04 的Git回購與GLFW項目

問題：無法復位GLFW文件。無論我嘗試過什麼，它們總是顯示爲已修改。

解決：

edit .gitattributes 

Comment out the line: # text=auto 

Save the file 

restore .gitattributes: git checkout .gitattributes 

Answer 5

我只能臨時刪除我的回購的.gitattributes文件（該文件定義* text=auto和*.c text）來解決這個問題。

刪除並修改後，我跑git status。即使在.gitattribute被放回原位後，他們也不會返回。

Answer 6

我在Windows上遇到了這個問題，但並沒有準備好考慮使用config --global core.autocrlf false的後果。我還沒有準備放棄其他私人分支機構和好東西，並開始使用新的克隆。我只需要完成一些事情。現在。

這個工作對我來說，對，你讓git的重寫工作目錄徹底的想法：

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

（請注意，運行剛剛git reset --hard不夠好，也不是對文件的純rm前reset正如在原來的問題的意見中所建議的）

Answer 7

我有一個.bat文件有同樣的問題（無法擺脫它在未跟蹤的文件）。 git checkout - 沒有工作，也沒有在這個頁面上的任何建議。只爲我工作的事情是應該做：

git stash save --keep-index 

然後刪除藏匿：

git stash drop 

Answer 8

我也有同樣的症狀，但已經通過不同的事情引起的。

我沒能：

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並再次執行git status時，它仍顯示「未跟蹤」文件。

經過與同事的幾次嘗試之後，我們發現它是由Grunt引起的！

由於Grunt已打開，並且因爲app.js已經從其他js文件生成，所以我們發現在每次使用js文件（也是這個app.js）進行操作後，grunt再次重新創建app.js。

Answer 9

另一種解決方案可以爲人們的工作，因爲沒有的文本選項爲我工作：

1. 與單行替換的.gitattributes內容：* binary。這告訴git將每個文件都視爲無法執行任何操作的二進制文件。
2. 檢查有問題的文件的消息是否消失;如果它不是你可以git checkout -- <files>將它們恢復到存儲庫版本
3. git checkout -- .gitattributes到.gitattributes文件恢復到初始狀態
4. 檢查文件仍沒有標記爲已改變。

Answer 10

當Linux的計算機上的repo貢獻者或者Cygwin和文件權限更改窗口工作時，也會發生此問題。 Git的只知道這個問題的755和644

實例，以及如何來檢查它：

git diff styleguide/filename 

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

爲了避免這種情況，你應該確保你安裝的git正確使用

git config --global core.filemode false 

Answer 11

兩次得到同樣的問題！這兩次都隱藏了我所做的一些改變，然後試圖將它們彈回。因爲我有很多文件被更改 - 不能彈出更改 - 但它們不是！他們是完全一樣的。

我現在認爲我已經嘗試了所有上述解決方案，但都沒有成功。嘗試

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

之後，我現在得到了在我的倉庫修改幾乎所有的文件。

當版本比較的文件，它說我已經刪除了所有的線，然後再添加。

一種干擾。現在我將在以後避免積攢..

唯一的解決辦法是克隆新的存儲庫，並重新開始。 （產地它最後一次）

Answer 12

這裏有很多的解決方案，我也許應該嘗試一些這些之前，我想到了我自己。反正這裏是一個更多...

我們的問題是，我們沒有執法的endlines和倉庫有DOS/Unix下的混合。更糟糕的是，它實際上是一個開源的回購，在這個位置，我們已經分叉。這個決定是由那些擁有操作系統存儲庫的主要所有者將所有的終端改爲Unix的，並且提交包括一個.gitattributes來強制執行行結束。

不幸的是這似乎導致這裏描述的問題，就像這裏曾經的代碼由之前合併DOS-2-Unix的做的改變將永遠被標記的文件，不能被還原。

在我的研究過程中，我碰到了 - https://help.github.com/articles/dealing-with-line-endings/ - 如果我再次面對這個問題，我會先試一試。

---

這裏是我做過什麼：

1. 我最初做了合併意識到我有這個問題之前，不得不放棄那 - git reset --hard HEAD（I ran into a merge conflict. How can I abort the merge?）

2. 我在VIM中打開有問題的文件並將其更改爲Unix（:set ff=unix）。像dos2unix的工具可以被用來代替當然

3. 致力於

4. 合併在master（主具有DOS -2- Unix的改變）

   git checkout old-code-branch; git merge master

5. 解決衝突和這些文件再次是DOS，因此在VIM中必須使用:set ff=unix。 （注意：我已經安裝了https://github.com/itchyny/lightline.vim這讓我看到的文件格式是在VIM狀態行什麼）

6. 承諾。全部排序！

Answer 13

如果您克隆存儲庫並立即看到掛起的更改，那麼存儲庫處於不一致的狀態。請不要從.gitattributes文件中註釋掉* text=auto。這是因爲存儲庫的所有者希望所有文件都與LF行尾一致存儲。

正如HankCa所述，遵循https://help.github.com/articles/dealing-with-line-endings/的說明是解決問題的方法。 EASY按鈕：

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 

然後合併（或拉入請求）的分支回購的所有者。

Answer 14

我遇到的問題是，Windows不關心文件名大小寫，但混帳。所以git存儲了文件的大寫和小寫版本，但只能簽出一個。

Answer 15

本頁沒有其他的工作。這終於爲我工作。不顯示未追蹤或提交的文件。

git add -A 
git reset --hard 

Answer 16

嘗試做一個

git的結帳-f

這應該清除當前工作的本地倉庫

Answer 17

我COMMITED所有的更改，然後做了所有的變化並在提交時撤銷。 這工作對我來說

git add。

git的承諾-m 「隨機提交」

的git的復位 - 硬HEAD〜1