の後git reset --hardに、セクションgit status内のファイルを表示しますChanges not staged for commit:。
私も試しましたがgit reset .、無駄にgit checkout -- .なりました。git checkout-index -f -a
では、どうすればこれらのステージングされていない変更を取り除くことができますか？
これは、VisualStudioプロジェクトファイルにのみヒットするようです。変。このペーストを参照してください：http：//pastebin.com/eFZwPn9Z。これらのファイルの特別な点は、.gitattributesに次のようなものがあることです。
*.sln eol=crlf
*.vcproj eol=crlf
*.vcxproj* eol=crlf
また、autocrlf私のグローバルではfalseに設定されています.gitconfig。それはどういうわけか関連があるでしょうか？
私は同じ問題を抱えていました、そしてそれは.gitattributesファイルに関連していました。ただし、問題の原因となったファイルの種類がに指定されていません.gitattributes。
実行するだけで問題を解決できました
git rm .gitattributes
git add -A
git reset --hard
次の手順でこの問題を解決しました
Gitのインデックスからすべてのファイルを削除します。
git rm --cached -r .
Gitインデックスを書き直して、すべての新しい行末を取得します。
git reset --hard
ソリューションは、行末を処理するためのGitの構成で説明されている手順の一部でした
Gitは、リポジトリにないファイルをリセットしません。だからあなたはできる：
$ git add .
$ git reset --hard
これにより、すべての変更がステージングされ、Gitがそれらのファイルを認識してからリセットします。
これが機能しない場合は、変更を隠してドロップしてみてください。
$ git stash
$ git stash drop
私は同じ問題を抱えており、隠し場所、ハードリセット、クリーン、またはそれらすべてでさえ、変更を残していました。問題であることが判明したのは、gitによって適切に設定されなかったxファイルモードでした。これは、gitforwindowsの「既知の問題」です。ローカルの変更は、実際のファイルの違いなしに、古いモード100755、新しいモード100644としてgitkおよびgitステータスで表示されます。
修正は、ファイルモードを無視することです。
git config core.filemode false
さて、私は問題を解決しました。
.gitattributes次の内容を含むファイルのようです。
*.sln eol=crlf
*.vcproj eol=crlf
*.vcxproj* eol=crlf
プロジェクトファイルがステージングされていないように見えるようにしました。それがなぜなのか私にはわかりません。gitの方法に精通している誰かが私たちに素晴らしい説明をしてくれることを本当に望んでいます。
私の修正は、これらのファイルを削除し、のautocrlf = false下[core]に追加することでした.git/config。
これは、すべての開発者がを持っている必要があるため、前の構成とまったく同じになるわけではありませんautocrlf = false。より良い修正を見つけたいのですが。
編集：
私は罪を犯した行にコメントし、コメントを外しました、そしてそれはうまくいきました。なに…私も…！
これが発生する可能性のある状況の1つは、問題のファイルが行末の正しい構成なしでリポジトリにチェックインされた場合（1）、リポジトリ内のファイルの行末が正しくないか、行末が混在している場合です。確認するにgit diffは、行末の変更のみが表示されることを確認します（これらはデフォルトでは表示されない場合があります。git diff | cat -vキャリッジリターンをリテラル^M文字として表示してみてください）。
その後、誰かが行末を正規化するために設定を追加.gitattributesまたは変更した可能性があります（2）。core.autocrlfまたはグローバル構成に基づいて.gitattributes、Gitは、要求された行終了正規化を適用するローカル変更を作業コピーに適用しました。残念ながら、何らかの理由でgit reset --hardこれらの行の正規化の変更を元に戻すことはできません。
ローカル行末がリセットされる回避策では、問題は解決しません。ファイルがgitによって「表示」されるたびに、正規化が再適用され、同じ問題が発生します。
最良のオプションは、リポジトリ内のすべての行末を正規化して、.gitattributesそれらの変更をコミットすることにより、gitに正規化を適用させることです。「 gitfilter-branchで行末を修正しようとしていますが、運がない」を参照してください。
本当にファイルへの変更を手動で元に戻したい場合、最も簡単な解決策は、変更されたファイルを消去してから、それらを復元するようにgitに指示することですが、この解決策は一貫して100％機能しないようです。時間（警告：変更したファイルに行末以外の変更がある場合は、これを実行しないでください!!）：
git status --porcelain | grep "^ M" | cut -c4- | xargs rm
git checkout -- .
ある時点でリポジトリ内の行末を正規化しない限り、この問題が発生し続けることに注意してください。
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で実行することもできます。Git-Uniteは必要なケースの変更をgitインデックスに適用し、それをリポジトリにコミットできます。
.gitattributes（1）これは、問題のファイルの定義がなく、Windowsを使用していて、デフォルトのグローバル設定を使用している人が原因である可能性がcore.autocrlfありますfalse（（2）を参照）。
（2）http://adaptivepatchwork.com/2012/03/01/mind-the-end-of-your-line/
$ git add -A
$ git reset --hard
私の場合、これはgitが追跡している空のファイルがたくさんあるときに役立ちました。
これのもう1つの原因は、大文字と小文字を区別しないファイルシステムである可能性があります。同じレベルのリポジトリに複数のフォルダがあり、名前が大文字と小文字だけが異なる場合は、これに見舞われることになります。Webインターフェイス（GitHubやVSTSなど）を使用してソースリポジトリを参照し、確認します。
変更を削除してから、隠し場所を削除できstashます。
git stash
git stash drop
cleanコマンドを実行します。
# Remove all untracked files and directories. (`-f` is `force`, `-d` is `remove directories`)
git clean -fd
これらの方法はどれも私にはうまくいきませんでした。唯一の解決策は、リポジトリ全体を削除して再クローン化することでした。これには、隠し、リセット、追加とリセット、clrf設定、大文字と小文字の区別などが含まれます。
を確認してください.gitattributes。
私の場合、私は*.js text eol=lfそれを持っていて、gitオプションcore.autocrlfはでしたtrue。
gitがファイルの行末を自動変換し、それを修正できず、git reset --hard HEAD何もしなかった場合の状況になります。
*.js text eol=lfコメントで修正し、コメントを外し.gitattributesます。
それはただのgitmagicのように見えます。
git for Windowsには、チェックアウト時にgitがランダムに間違った行末を書き込むという問題があり、唯一の回避策は、他のブランチをチェックアウトして、変更を無視するようにgitに強制することだと思います。次に、実際に作業したいブランチをチェックアウトします。
git checkout master -f
git checkout <your branch>
これにより、意図的に行った変更が破棄されることに注意してください。チェックアウト直後にこの問題が発生した場合にのみ、これを行ってください。
編集：私は実際に初めて幸運に恵まれたかもしれません。ブランチを切り替えた後、私は再び少し得たことがわかりました。ブランチの変更後に変更されたとgitが報告していたファイルが変更されたことが判明しました。（どうやら、gitが一貫してCRLF行末をファイルに適切に適用していなかったためです。）
Windows用の最新のgitにアップデートしましたが、問題が解決したことを願っています。
私も同じ問題を抱えていました。私はそうしgit reset --hard HEADましたが、それでも私がするたびにgit status、いくつかのファイルが変更されているのを見ていました。
私の解決策は比較的単純でした。IDE（ここではXcode）を閉じ、コマンドライン（ここではMac OSのターミナル）を閉じて、もう一度試してみましたが、機能しました。
それでも、問題の原因を見つけることができませんでした。
同様の問題.gitattributesが発生しましたが、私の場合はGitHubのLFSが関係していました。.gitattributesこれは正確にはOPのシナリオではありませんが、ファイルが何をするのか、そしてなぜそれが「ファントム」の違いの形でステージングされていない変更につながる可能性があるのかを説明する機会を提供すると思います。
私の場合、ファイルは、時間の初めからのように、すでに私のリポジトリにありました。最近のコミットでは、少し広すぎるパターンを使用して新しいルールを追加し、git-lfs trackこの古いファイルと一致するようになりました。私はこのファイルを変更したくなかったことを知っています。私はファイルを変更しなかったことを知っていますが、今はステージングされていない変更にあり、そのファイルのチェックアウトやハードリセットの量はそれを修正するつもりはありませんでした。なんで？
GitHub LFS拡張機能は、主にファイルgitを介したアクセスを提供するフックを活用することで機能し.gitattributesます。一般に、のエントリは、.gitattributes一致するファイルの処理方法を指定します。OPの場合、行末の正規化に関係していました。私の場合、LFSにファイルストレージを処理させるかどうかでした。いずれの場合も、git計算時に表示される実際のファイルgit diffは、ファイルを検査するときに表示されるファイルと一致しません。したがって、ファイルに一致するパターンを使用してファイルの処理方法を変更すると、ファイル.gitattributesに実際に変更がない場合でも、ステータスレポートにステージングされていない変更として表示されます。
とはいえ、この質問に対する私の「答え」は、.gitattributesファイルの変更がやりたいことである場合は、実際には変更を追加して先に進む必要があるということです。そうでない場合は、を修正して、.gitattributesやりたいことをより適切に表現します。
GitHub LFS仕様-オブジェクト内のファイルをハッシュ付きの単純なテキストファイルに置き換えるために、cleanおよび関数呼び出しにフックする方法の詳細な説明。smudgegit
gitattributesドキュメント-ドキュメントの処理方法をカスタマイズするために利用できるものに関するすべての詳細git。
単にgitrestoreを試してみてください。
それはgitが言うことであり、それは機能しています
同様の問題ですが、私は表面上だけだと確信しています。とにかく、それは誰かを助けるかもしれません：私がしたこと（FWIW、SourceTreeで）：コミットされていないファイルを隠してから、ハードリセットをしました。
他の回答が指摘しているように、問題はラインエンドの自動修正によるものです。*.svgファイルでこの問題が発生しました。プロジェクトのアイコンにsvgファイルを使用しました。
この問題を解決するには、以下の行を.gitattributesに追加して、svgファイルをテキストではなくバイナリとして処理する必要があることをgitに通知します。
*.svgバイナリ
同様の状況で。行末のさまざまなエンコーディング（ .asp、.js、.css ...本質ではない）を1つのファイルに詰め込むことができた多くのプログラマーによる長年の苦痛の結果として。少し前に.gitattributesを拒否しました。左レポautorclf = trueとの設定safecrlf = 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
私が遭遇した別の可能性は、リポジトリ内のパッケージの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フォルダaに移動するgit statusと、次の結果が得られます。
HEAD detached at 7515f05
そして、次のコマンドで問題を修正するmaster必要があります。ローカルブランチに置き換える必要があります。
git checkout master
そして、ローカルブランチがリモートブランチの背後にある量のコミットになるというメッセージが表示されます。git pullそして、あなたは森の外にいるはずです！
何らかの理由で
git add .
動作しませんでしたが
$ git add -A
うまくいった！