git statusは変更を示し、git checkout — <file>はそれらを削除しません

作業コピーへのすべての変更を削除したいと思います。
実行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")

この動作を引き起こす可能性がある複数の問題があります。

行末正規化

私もこのような問題を抱えていました。gitが自動的にcrlfをlfに変換します。これは通常、単一のファイルに行末が混在していることが原因です。ファイルはインデックスで正規化されますが、gitが再び非正規化して作業ツリー内のファイルと比較すると、結果は異なります。

ただし、これを修正する場合は、core.autocrlfを無効にし、すべての行末をlfに変更してから、再度有効にする必要があります。または、次のようにして完全に無効にすることもできます。

git config --global core.autocrlf false

core.autocrlfの代わりに、.gitattributeファイルの使用を検討することもできます。これにより、リポジトリを使用するすべてのユーザーが同じ正規化ルールを使用して、行末が混在してリポジトリに入るのを防ぐことができます。

また、不可逆な正規化が実行されるときにgitが警告するようにしたい場合は、core.safecrlfを警告に設定することを検討してください。

gitのマンページには次のように書かれています。

CRLF変換では、データが破損する可能性がわずかにあります。autocrlf = trueは、コミット時にCRLFをLFに変換し、チェックアウト時にLFをCRLFに変換します。コミット前にLFとCRLFが混在するファイルは、gitでは再作成できません。テキストファイルの場合、これは正しいことです。これは、行末を修正して、リポジトリ内の行末がLFのみになるようにします。しかし、誤ってテキストとして分類されたバイナリファイルの場合、変換によってデータが破損する可能性があります。

大文字と小文字を区別しないファイルシステム

大文字と小文字を区別しないファイルシステムで、大文字と小文字が異なる同じファイル名がリポジトリにある場合、gitは両方をチェックアウトしようとしますが、ファイルシステムに残るのは1つだけです。gitが2番目のファイルを比較しようとすると、間違ったファイルと比較されます。

解決策は、大文字と小文字を区別しないファイルシステムに切り替えることですが、ほとんどの場合、これは実行できないか、別のファイルシステム上のファイルの1つを名前変更してコミットすることはできません。

私はWindowsでこの問題を抱えていましたが、使用による影響を検討するconfig --global core.autocrlf false準備ができていませんでした。また、保管場所にある他のプライベートブランチやグッズを放棄して、新しいクローンを作成する準備もありませんでした。私は何かを成し遂げる必要があるだけです。さて。

これは私にうまくいきました、あなたはgitにあなたの作業ディレクトリを完全に書き直させるという考えで：

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

（元の質問へのコメントで提案されているように、実行するだけでgit reset --hardは十分ではなくrm、以前のファイルでは明白ではなかったことに注意してくださいreset）

テキストオプションのどれも私のために働かなかったので人々のために働くかもしれない別の解決策：

1. の内容を.gitattributes1行に置き換えます* binary。これは、すべてのファイルをバイナリファイルとして扱うようにgitに指示します。
2. 問題のあるファイルのメッセージがなくなっていることを確認してください。そうでない場合はgit checkout -- <files>、それらをリポジトリバージョンに復元できます。
3. git checkout -- .gitattributes.gitattributesファイルを初期状態に復元する
4. ファイルがまだ変更済みとしてマークされていないことを確認してください。

この問題を抱えている将来の人々のために：ファイルモードを変更しても、同じ症状が出る可能性があります。 git config core.filemode false修正します。

これは私を夢中にさせてきました。特に、オンラインで見つけられる解決策がなければこれを修正することができませんでした。ここで私はそれを解決した方法です。これは同僚の仕事なので、ここでクレジットを取ることはできません:)

問題の原因：gitの最初のインストールで、Windowsで自動行変換が行われませんでした。これにより、GLFWへの最初のコミットで適切な行末がなくなりました。

注：これはローカルソリューションのみです。リポジトリをクローンする次の人はまだこの問題で立ち往生しています。永続的な解決策は、https： //help.github.com/articles/dealing-with-line-endings/#re-normalizing-a-repositoryにあります。

セットアップ：Xfwuntu 12.04 Gfw repo with glfw project

問題：glfwファイルをリセットできません。私が何を試したかに関係なく、それらは常に変更済みとして表示されます。

解決済み：

edit .gitattributes

Comment out the line:    # text=auto

Save the file

restore .gitattributes:   git checkout .gitattributes

同じ問題の.batファイルがありました（追跡されていないファイルでそれを取り除くことができませんでした）。git checkout-機能せず、このページの提案も機能しませんでした。私のために働いた唯一のことはすることでした：

git stash save --keep-index

そして、スタッシュを削除するには：

git stash drop

同じ問題を2回受けた！どちらの場合も、いくつかの変更を隠しておき、それらを元に戻そうとしました。変更されたファイルがたくさんあるので、変更をポップできませんでした-しかし、そうではありません！それらはまったく同じです。

私は今、上記の解決策をすべて試しましたが、成功しなかったと思います。試した後

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

リポジトリ内のほぼすべてのファイルが変更されました。

ファイルを比較すると、すべての行を削除してから再度追加したと表示されます。

ちょっと気になる。今後は隠れることはありません。

唯一の解決策は、新しいリポジトリを複製してやり直すことです。（前回作った）

やってみてください

git checkout -f

これで、現在作業中のローカルリポジトリのすべての変更がクリアされます。

これを修正するには、リポジトリの.gitattributesファイル（とが定義され* text=autoている*.c text）を一時的に削除するしかありませんでした。

git status削除後に実行したところ、変更内容は失われました。.gitattributesを元に戻した後も返されませんでした。

一貫した行末があることは良いことです。たとえば、些細なことではありますが、不要なマージはトリガーされません。Visual Studioが行末が混在するファイルを作成するのを見てきました。

また、（Linux上の）bashなどの一部のプログラムでは、.shファイルをLFで終了する必要があります。

これを確実に行うには、gitattributesを使用できます。autcrlfの値に関係なく、リポジトリレベルで機能します。

たとえば、次のような.gitattributesを設定できます。* text = auto

場合に応じて、ファイルタイプ/拡張子ごとに具体的に指定することもできます。

次に、autocrlfはWindowsプログラムの行末をローカルに変換できます。

C＃/ C ++ / Java / Ruby / R、Windows / Linuxの混合プロジェクトでは、これはうまく機能しています。これまでのところ問題はありません。

私も同じ症状がありましたが、別の原因が原因です。

私はできませんでした：

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は他の2つのjsファイルから生成されているため、jsファイル（およびこのapp.js）を使用した各操作の後、再度app.jsを再作成する必要があることがわかりました。

この問題は、リポへの寄稿者がLinuxマシンで動作する場合、または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

ここには多くの解決策があり、自分で考え出す前にこれらのいくつかを試してみるべきでした。とにかくここにもう一つあります...

私たちの問題は、エンドラインを強制せず、リポジトリにDOS / Unixが混在していたことです。さらに悪いことに、それは実際にはこのポジションのオープンソースのリポジトリであり、私たちがフォークしたものでした。OSリポジトリの主な所有権を持つ人々がすべてのエンドラインをUnixに変更する.gitattributesことを決定し、行末を強制することを含むコミットが行われました。

残念ながら、これは、DOS-2-Unixが実行される前のコードをマージすると、ファイルが永久に変更済みとしてマークされ、元に戻すことができないという、ここで説明したような問題を引き起こすようでした。

これについての私の調査中に私は出会いました-https://help.github.com/articles/dealing-with-line-endings/-この問題に再び直面した場合、まずこれを試すことから始めます。

これが私がしたことです：

1. 私はこの問題に気づく前に最初にマージを行い、それを中止しなければなりませんでした- git reset --hard HEAD（マージの競合に遭遇しました。マージを中止するにはどうすればよいですか？）

2. 問題のファイルをVIMで開き、Unix（:set ff=unix）に変更しました。dos2unixもちろん代わりに使用できるようなツール

3. 関与する

4. をマージしmasterました（マスターにはDOS-2-Unixの変更があります）

   git checkout old-code-branch; git merge master

5. 競合が解決され、ファイルが再びDOSになったため:set ff=unix、VIMで実行する必要がありました。（私がhttps://github.com/itchyny/lightline.vimをインストールしたことに注意してください。これにより、VIMステータスラインのファイル形式を確認できます）

6. 関与する。すべてソートされました！

私が遭遇した問題は、ウィンドウズがファイル名の大文字化を気にしないことですが、gitは気にします。したがって、gitはファイルの小文字バージョンと大文字バージョンを格納しましたが、チェックアウトできるのは1つだけでした。

私はすべての変更をコミットし、コミット時に元に戻しました。これは私のために働いた

git add。

git commit -m "ランダムコミット"

git reset --hard HEAD〜1

通常、GITですべての変更と新しいファイルをクリアするには、次の2つのコマンドが非常にうまく機能します（注意してください。これにより、作成したすべての新しいファイルとフォルダーが削除され、すべての変更されたファイルが現在の状態に復元されますコミット）：

$ git clean --force -d
$ git checkout -- .

たぶん、より良いオプションは、次のようにオプションのメッセージで「git stash push」を実行することです：

$ git stash push -m "not sure if i will need this later"

これにより、すべての新しいファイルと変更されたファイルも消去されますが、復元する場合に備えて、すべてのファイルが隠されています。GITのスタッシュはブランチからブランチへと移動するため、必要に応じて別のブランチに復元できます。

補足として、新しく追加したファイルをすでにいくつかステージングしていて、それらを削除したい場合は、これでうまくいくはずです。

$ git reset --hard

上記のすべてが機能しない場合は、少し前に私のために機能したものを以下に示します：

この問題に何度か遭遇しました。現在、雇用主から提供されたWindows 10マシンで開発しています。今日、この特定のgitの動作は、「開発」ブランチから新しいブランチを作成したことが原因でした。なんらかの理由で、「開発」ブランチに切り替えた後、一見ランダムなファイルが永続化され、「git status」で「変更済み」として表示されていました。

また、その時点では別のブランチをチェックアウトできなかったため、「開発」ブランチに行き詰まりました。

これは私がやったことです：

$ git log

今日初めに「開発」から作成した新しいブランチが最初の「コミット」メッセージに表示され、「HEAD->開発、オリジン/開発、オリジン/ヘッド、The-branch-i-created」の最後で参照されていることに気付きました-以前の今日 "。

本当に必要なかったので、削除しました。

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

変更されたファイルはまだ表示されていたので、次のようにしました。

$ git stash

これは私の問題を解決しました：

$ git status
On branch develop
Your branch is up to date with 'origin/develop'.

nothing to commit, working tree clean

もちろん$ git stash list、隠された変更が表示されます。また、隠し場所はほとんどなく、必要もなかった$ git stash clearため、すべての隠し場所を削除しました。

注：私の前に誰かがここで提案したことをやろうとしませんでした：

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

これも機能している可能性があります。次回この問題が発生した場合は、必ず試してみます。

リポジトリのクローンを作成し、保留中の変更がすぐに表示される場合、リポジトリは不整合な状態にあります。ファイル* text=autoからコメントアウトしないでください.gitattributes。これは、リポジトリの所有者がすべてのファイルをLFの行末で一貫して保存することを望んでいるため、特にそこに置かれました。

HankCaで述べられているように、https： //help.github.com/articles/dealing-with-line-endings/の指示に従うことが、問題を解決するための方法です。簡単なボタン：

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

次に、ブランチをレポの所有者にマージ（またはプルリクエスト）します。

このページの他の部分は機能しませんでした。これでようやくうまくいきました。追跡されていない、またはコミットされたファイルは表示されません。

git add -A
git reset --hard

私にとっての問題は、コマンドを実行するときにVisual Studioが開かれたことでした

git checkout <file>

Visual Studioを閉じた後、コマンドは機能し、スタックから作業を最終的に適用できました。したがって、SourceTree、SmartGit、NotePad、NotePad ++、その他のエディターなど、コードに変更を加える可能性のあるすべてのアプリケーションを確認してください。

私たちの会社でも同様の状況に直面しました。提案された方法のどれも私たちを助けませんでした。調査の結果、問題が判明した。問題は、Gitに2つのファイルがあり、その名前がシンボルのレジスターのみが異なることでした。Unixシステムはそれらを2つの異なるファイルと見なしていましたが、Windowsは狂っていました。この問題を解決するために、サーバー上のファイルの1つを削除しました。その後、Windowsのローカルリポジトリで、次のいくつかのコマンドを（異なる順序で）支援しました。

git reset --hard
git pull origin
git merge

私は.git / configを編集してそれを解決し、追加しました：

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

次に、.git / refs / heads / name_branchに移動し、最後のコミットのIDを配置しましたenter code here

私はそれをこのように解決しました：

1. 必要な正しいコードの内容をコピーします
2. 問題の原因となっているファイル（元に戻せないファイル）をディスクから削除します。これで、削除済みとしてマークされた同じファイルの両方のバージョンが見つかります。
3. ファイルの削除をコミットします。
4. 同じ名前でファイルを再度作成し、手順1でコピーした正しいコードを貼り付けます
5. 新しいファイルの作成をコミットします。

それが私にとってうまくいきました。

ここで提案された解決策の1つは機能しませんでした。ファイルが実際にはいくつかの特殊文字へのリンクであることがわかりました。

% ls -l StoreLogo.png
lrwxrwxrwx 1 janus janus 8 Feb 21 10:37 StoreLogo.png -> ''$'\211''PNG'$'\r\n\032\n'

% git status    
Changes not staged for commit:
    modified:   StoreLogo.png

% git rm --cached -r StoreLogo.png
rm 'src/GWallet.Frontend.XF.UWP/Assets/StoreLogo.png'

% git reset StoreLogo.png         
Unstaged changes after reset:
M   src/GWallet.Frontend.XF.UWP/Assets/StoreLogo.png

% git status                      
Changes not staged for commit:
    modified:   StoreLogo.png