git reset --hard後にステージングされていない変更が残ります
タイトルはそれをすべて言います。
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
また、グローバル.gitconfigでautocrlfがfalseに設定されています。それは何らかの形で関連性がありますか？
さて、私はちょっと問題を解決しました。
.gitattributesファイルには次のものが含まれているようです。
*.sln eol=crlf
*.vcproj eol=crlf
*.vcxproj* eol=crlf
プロジェクトファイルがステージングされていないように見えました。なぜそうなのかはわかりませんが、gitのやり方を知っている人が素敵な説明をしてくれることを本当に望んでいます。
私の修正は、これらのファイルを削除し、autocrlf = falseの[core]の下に.git/configを追加することでした。
すべての開発者がautocrlf = falseを持っている必要があるため、これは以前の設定とまったく同じではありません。より良い修正を見つけたいです。
編集：
批判的な行にコメントし、コメントを外して、うまくいきました。なんて...私もしない...！
同じ問題があり、.gitattributesファイルに関連していました。ただし、問題を引き起こしたファイルの種類は.gitattributesで指定されていません。
私は単に実行することで問題を解決することができました
git rm .gitattributes
git add -A
git reset --hard
解決済み!!!
次のstpesを使用してこの問題を解決しました
1）Gitのインデックスからすべてのファイルを削除します。
git rm --cached -r .
2）Gitインデックスを書き換えて、すべての新しい行末を取得します。
git reset --hard
解決策は、gitサイトで説明されている手順の一部でした https://help.github.com/articles/dealing-with-line-endings/
Gitは、リポジトリにないファイルをリセットしません。だからあなたはできる：
$ git add .
$ git reset --hard
これにより、すべての変更がステージングされ、Gitがこれらのファイルを認識し、リセットされます。
これが機能しない場合は、変更を隠してドロップしようとすることができます。
$ git stash
$ git stash drop
Git for Windowsを使用している場合、これはおそらく問題です
私は同じ問題を抱えており、スタッシュ、ハードリセット、クリーン、またはそれらすべてがまだ変更を残しています。問題であることが判明したのは、gitによって適切に設定されなかったxファイルモードでした。これはgit for windowsの「既知の問題」です。ローカルの変更は、実際のファイルの違いなしに、古いモード100755新しいモード100644としてgitkおよびgitステータスで表示されます。
修正は、ファイルモードを無視することです。
git config core.filemode false
考えられる原因＃1-行末の正規化
これが発生する可能性のある状況の1つは、問題のファイルが行末の正しい構成なしでリポジトリにチェックインされた場合です（1）。結果として、リポジトリ内のファイルの行末が正しくないか、行末が混在しています。確認するには、git diffが行末の変更のみを表示することを確認します（デフォルトでは表示されない場合があります。git diff | cat -vを試して、キャリッジリターンをリテラル^M文字として表示してください）。
その後、おそらく誰かが.gitattributesを追加するか、core.autocrlf設定を変更して、行末を正規化しました（2）。 .gitattributesまたはグローバル設定に基づいて、Gitは作業コピーにローカル変更を適用し、要求された行末正規化を適用します。残念ながら、何らかの理由でgit reset --hardはこれらの行の正規化の変更を元に戻しません。
溶液
ローカル回線の末尾がリセットされる回避策では、問題は解決しません。 gitがファイルを「見る」たびに、正規化が再試行され、同じ問題が発生します。
最良のオプションは、レポジトリ内のすべての行末を.gitattributesに一致するように正規化し、それらの変更をコミットすることにより、gitに希望する正規化を適用させることです- gitで行末を修正しようとするfilter-branch、しかし運がない 。
ファイルへの変更を手動で元に戻したい場合、最も簡単な解決策は変更されたファイルを消去し、gitにそれらを復元するように指示することです。ただし、この解決策は100％時刻（警告：変更されたファイルに行末以外の変更がある場合、これを実行しないでください!!）：
git status --porcelain | grep "^ M" | cut -c4- | xargs rm
git checkout -- .
ある時点でリポジトリの行末を正規化しない限り、この問題が発生し続けることに注意してください。
考えられる原因＃2-大文字と小文字を区別しない
2番目の考えられる原因は、WindowsまたはMac OS/Xでの大文字と小文字の区別がありません。たとえば、次のようなパスがリポジトリに存在するとします。
/foo/bar
Linuxの誰かがファイルを/foo/Barにコミットし（おそらくビルドツールまたはそのディレクトリを作成した何かが原因）、プッシュします。 Linuxでは、これは実際には2つの個別のディレクトリになりました。
/foo/bar/fileA
/foo/Bar/fileA
WindowsまたはMacでこのリポジトリをチェックアウトすると、変更できないfileAになります。リセットするたびに、Windowsのgitは/foo/bar/fileAをチェックアウトし、Windowsは大文字と小文字を区別せず、 fileAに/foo/Bar/fileAを使用すると、「変更」されます。
別のケースは、リポジトリに存在する個々のファイルであり、大文字と小文字を区別しないファイルシステムでチェックアウトすると、重複します。例えば：
/foo/bar/fileA
/foo/bar/filea
そのような問題を引き起こす可能性のある他の同様の状況があるかもしれません。
大文字と小文字を区別しないファイルシステムのgitは、この状況を実際に検出し、有用な警告メッセージを表示する必要がありますが、現在は表示されません（これは将来変更される可能性があります- この説明 および関連する提案されたgit.gitのパッチを参照してください）メーリングリスト）。
溶液
解決策は、gitインデックス内のファイルのケースとWindowsファイルシステム上のケースを一致させることです。これは、物事の本当の状態を表示するLinuxで行うことができます。非常に便利なオープンソースユーティリティ Git-Unite を使用して、WindowsでORを実行します。 Git-Uniteは、必要なケースの変更をgitインデックスに適用し、リポジトリにコミットできます。
（1）これは、Windowsを使用し、問題のファイルの.gitattributes定義がなく、core.autocrlfのデフォルトのグローバル設定であるfalseを使用している可能性が高い（（2）を参照） ）。
（2） http://adaptivepatchwork.com/2012/03/01/mind-the-end-of-your-line/
この別の原因は、大文字と小文字を区別しないファイルシステムかもしれません。同じレベルのリポジトリに複数のフォルダーがあり、その名前が大文字と小文字のみが異なる場合、これに見舞われます。 Webインターフェース（GitHubやVSTSなど）を使用してソースリポジトリを参照します。
他の回答が機能しない場合は、ファイルを追加してからリセットしてください
$ git add -A
$ git reset --hard
私の場合、これはgitが追跡している空のファイルがたくさんあるときに役立ちました。
.gitattributesを確認してください。
私の場合、*.js text eol=lfがあり、gitオプションcore.autocrlfはtrueでした。
Gitがファイルの行末を自動変換し、それを修正することを妨げ、git reset --hard HEADでさえ何もしなかった状況に私を連れて行きます。
*.js text eol=lfに.gitattributesをコメントして修正し、その後コメントを外しました。
Git魔法のように見えます。
これらの方法はどれもうまくいきませんでした。唯一の解決策は、レポ全体を破棄し、クローンを再作成することでした。これには、スタッシング、リセット、追加とリセット、clrf設定、大文字と小文字の区別などが含まれます。
cleanコマンドを実行します：
# Remove all untracked files and directories. (`-f` is `force`, `-d` is `remove directories`)
git clean -fd
stash 変更を削除して、スタッシュをドロップできます。
git stash
git stash drop
.gitattributesが関係する同様の問題にぶつかりましたが、私の場合はGitHubのLFSが関係していました。これはまさにOPのシナリオではありませんが、.gitattributesファイルが何をするのか、なぜ「ファントム」差分の形でステージングされていない変更につながるのかを説明する機会を提供すると思います。
私の場合、時間の初めからなど、ファイルはすでに私のリポジトリにありました。最近のコミットで、ちょっと広すぎる後知恵のパターンを使用して新しいgit-lfs trackルールを追加し、この古いファイルと一致するようになりました。このファイルを変更したくないことはわかっています。私はファイルを変更しなかったことを知っていますが、今はステージングされていない変更であり、そのファイルのチェックアウトやハードリセットの量はそれを修正しませんでした。どうして？
GitHub LFS拡張機能は、gitが.gitattributesファイルを介してアクセスを提供するフックを活用することによって主に機能します。通常、.gitattributesのエントリは、一致するファイルの処理方法を指定します。 OPの場合、行末の正規化に関係していました。私の場合、LFSにファイルストレージを処理させるかどうかでした。いずれの場合も、git diffの計算時にgitが実際に見るファイルは、ファイルを検査するときに見るファイルと一致しません。したがって、ファイルに一致する.gitattributesパターンを介してファイルの処理方法を変更すると、ファイルに実際に変更がない場合でも、ステータスレポートにステージングされていない変更として表示されます。
そうは言っても、質問に対する私の「答え」は、.gitattributesファイルの変更があなたがしたいことであるなら、あなたは本当に変更を追加して先に進むべきだということです。そうでない場合は、.gitattributesを修正して、やりたいことをより適切に表現します。
参照資料
GitHub LFS仕様 -
cleanおよびsmudge関数呼び出しにフックして、gitオブジェクト内のファイルをハッシュ付きの単純なテキストファイルに置き換える方法の詳細な説明。gitattributes Documentation -
gitがドキュメントを処理する方法をカスタマイズするために利用できるものに関するすべての詳細。
Git for Windowsには問題があり、gitはチェックアウト時に間違った行末をランダムに書き込み、唯一の回避策は他のブランチをチェックアウトし、gitに強制的に変更を無視させることです。次に、実際に作業したいブランチをチェックアウトします。
git checkout master -f
git checkout <your branch>
これにより、意図的に加えた変更がすべて破棄されるため、チェックアウト直後にこの問題が発生した場合にのみ実行してください。
編集：私は実際に初めて幸運になったかもしれません。ブランチを切り替えた後、再びビットを得たことがわかりました。ブランチの変更が変更された後、Gitが変更されたと報告していることが判明しました。 （どうやらgitはファイルに終わるCRLF行を一貫して適切に適用していなかったためです。）
Windows用の最新のgitに更新し、問題が解決したことを願っています。
他の答えが指摘したように、問題はラインエンドの自動修正によるものです。 * .svgファイルでこの問題が発生しました。プロジェクトのアイコンにsvgファイルを使用しました。
この問題を解決するために、.gitattributesに次の行を追加して、svgファイルをテキストではなくバイナリとして扱う必要があることをgitに通知しました
* .svgバイナリ
同じ問題がありました。 git reset --hard HEADを実行しましたが、git statusを実行するたびに、一部のファイルが変更されているのを確認していました。
私の解決策は比較的簡単でした。 IDE（ここではXcode）を閉じ、コマンドライン（ここではMac OSのターミナル）を閉じて、もう一度試してみましたが、うまくいきました。
しかし、私は問題の原因を見つけることができませんでした。
似たような問題ですが、表面上だけだと確信しています。とにかく、それは誰かを助けるかもしれません：私がしたこと（SourceTreeのFWIW）：コミットされていないファイルを隠してから、ハードリセットをしました。
私が遭遇した別の可能性は、リポジトリ内のパッケージの1つが切り離されたHEADで終わったということでした。ここで答えが役に立たず、このようなgitステータスメッセージが表示された場合、同じ問題が発生している可能性があります。
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そして、あなたは森の外にいるはずです！
同様の状況で。行末（。asp、. js、.cssの異なるエンコーディングを詰め込むことができた多くのプログラマーによる長年の苦痛の結果...本質ではない）1つのファイルに。しばらく前に.gitattributesを拒否しました。リポジトリの設定はautorclf = true andsafecrlf = warnのままです。
最後の問題は、行末の異なるアーカイブから同期するときに発生しました。アーカイブからコピーした後、gitステータスで多くのファイルがノートで変更されます
The line will have its original line endings in your working directory. warning: LF will be replaced by CRLF in ...
Gitで作業ツリーの行末を正規化する方法？ からのヒント
git add -u