の後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

また、autocrlf私のグローバルではfalseに設定されています.gitconfig。それは何とか関係がありますか？

同じ問題があり、.gitattributesファイルに関連していました。ただし、問題の原因となったファイルの種類はで指定されていません.gitattributes。

実行するだけで問題を解決できました

git rm .gitattributes
git add -A
git reset --hard

解決しました!!!

次の手順を使用してこの問題を解決しました

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の「既知の問題」です。ローカルの変更は、実際のファイルの違いなしに、gitkおよびgitステータスで古いモード100755新しいモード100644として表示されます。

修正はファイルモードを無視することです：

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つは、問題のファイルが行末の正しい構成（1）なしでリポジトリにチェックインされ、その結果、ファイルがリポジトリ内に不正な行末または行末混合である場合です。確認するにgit diffは、行末の変更のみが表示されることを確認します（これらはデフォルトでは表示されない場合があります。git diff | cat -v改行をリテラル^M文字として表示してみてください）。

その後、誰かがおそらく行末を正規化.gitattributesするためにcore.autocrlf設定を追加または変更しました（2）。.gitattributesまたはグローバル構成に基づいて、Gitはリクエストされた行末の正規化を適用するローカル変更を作業コピーに適用しました。残念ながら、何らかの理由でgit reset --hardこれらの行の正規化の変更は元に戻せません。

解決

ローカルの行末がリセットされる回避策は問題を解決しません。ファイルがgitによって「認識」されるたびに、正規化が再試行され、同じ問題が発生します。

最適なオプションは、リポジトリにあるすべての行末を正規化してに一致させる正規化をgitに適用させ.gitattributes、それらの変更をコミットすることです-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は大文字と小文字を区別しないため、fileAwith の内容を上書きし/foo/Bar/fileA、結果として「変更」されます。

別のケースは、リポジトリに存在する個々のファイルであり、大文字と小文字を区別しないファイルシステムでチェックアウトすると、重複します。例えば：

/foo/bar/fileA
/foo/bar/filea

このような問題を引き起こす可能性のある他の同様の状況がある可能性があります。

大文字小文字を区別しないファイルシステム上のgitのは本当にこのような状況を検出し、有用な警告メッセージを表示し、それが現在（これは将来変更される可能性-を参照していないはずです。この議論をしてgit.gitメーリングリストで提案したパッチを関連します）。

解決

解決策は、gitインデックスのファイルのケースとWindowsファイルシステムのケースを一致させることです。これは、実際の状態を表示するLinuxで実行するか、非常に便利なオープンソースユーティリティGit-Uniteを使用するWindowsで実行できます。Git-Uniteは必要なケースの変更をgitインデックスに適用し、リポジトリにコミットすることができます。

（1）これは.gitattributes、問題のファイルの定義なしで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が追跡していた空のファイルがたくさんあったときに役立ちました。

別の原因としては、大文字と小文字を区別しないファイルシステムが考えられます。リポジトリ内に同じレベルの複数のフォルダがあり、大文字と小文字のみが異なる場合、これに遭遇します。Webインターフェース（GitHubやVSTSなど）を使用してソースリポジトリを参照し、確認します。

詳細：https : //stackoverflow.com/a/2016426/67824

stash変更を取り除いてから、隠しておくことができます。

git stash
git stash drop

これらの方法はどれも私にとってはうまくいきませんでした。唯一の解決策は、リポジトリ全体をnukeしてクローンを再作成することでした。これには、隠し、リセット、追加、リセット、clrf設定、大文字と小文字の区別などが含まれます。

cleanコマンドを実行します。

# Remove all untracked files and directories. (`-f` is `force`, `-d` is `remove directories`)

git clean -fd

を確認してください.gitattributes。

私の場合、私は*.js text eol=lfそれに持っていて、gitオプションcore.autocrlfはでしたtrue。

gitがファイルの行末を自動変換し、修正することがgit reset --hard HEADできず、何もしなかった場合の状況に私を導きます。

私はコメントでそれを修正*.js text eol=lf私の中で.gitattributes、それの後にそれをコメント解除しました。

ちょうどgit magicのように見えます。

私も同様の問題にぶつかりました.gitattributesが、私の場合はGitHubのLFSが関係していました。これは正確にOPのシナリオではありませんが、.gitattributesファイルが何をするのか、なぜ「ファントム」な違いの形で段階的でない変更につながるのかを説明する機会になると思います。

私の場合、ファイルは最初からすでに私のリポジトリにありました。最近のコミットで、git-lfs track後から少し広すぎるパターンを使用して新しいルールを追加し、最終的にこの古いファイルに一致させました。このファイルを変更したくないことはわかっています。ファイルを変更しなかったのはわかっていますが、今は段階的な変更ではなく、そのファイルのチェックアウトやハードリセットを行っても修正されませんでした。どうして？

GitHub LFS拡張機能は、主にgit、.gitattributesファイルを介したアクセスを提供するフックを利用して機能します。通常、のエントリは、.gitattributes一致するファイルの処理方法を指定します。OPの場合、それは行末の正規化に関係していました。私の場合、それはLFSにファイルストレージを処理させるかどうかでした。どちらの場合でも、gitaを計算するときに表示される実際のファイルはgit diff、ファイルを検査するときに表示されるファイルと一致しません。したがって、.gitattributes一致するパターンを介してファイルの処理方法を変更すると、実際にはファイルに変更がない場合でも、ステータスレポートにステージングされていない変更として表示されます。

そうは言っても、私の質問に対する「答え」は、.gitattributesファイルの変更があなたがやりたいことである場合、本当に変更を追加して次に進むべきだということです。そうでない場合は、を修正して、.gitattributesやりたいことをより適切に表します。

参考文献

1. GitHub LFS仕様 - オブジェクト内のファイルをハッシュ付きの単純なテキストファイルに置き換えるために、関数呼び出しcleanやsmudge関数呼び出しにフックする方法についての優れた説明git。

2. gitattributesのドキュメント - ドキュメントのgit処理方法をカスタマイズするために利用できるすべての詳細。

私も同じ問題を抱えていました。私はやったgit reset --hard HEADが、それでも毎回私がやったgit status修正として、私はいくつかのファイルを見ていました。

私の解決策は比較的簡単でした。IDE（ここではXcode）を閉じてコマンドライン（ここではMac OSのターミナル）を閉じ、もう一度試してみましたが、うまくいきました。

それでも、問題の原因を見つけることはできませんでした。

私はgit for Windowsに問題があると思います。gitはチェックアウト時に間違った行末をランダムに書き込み、唯一の回避策は他のブランチをチェックアウトしてgitに変更を無視させることです。次に、実際に作業したいブランチをチェックアウトします。

git checkout master -f
git checkout <your branch>

これにより、意図的に行った変更が破棄されることに注意してください。これは、チェックアウト直後にこの問題が発生した場合にのみ行ってください。

編集：私は実際に初めてラッキーだったかもしれません。ブランチを切り替えた後、再びビットを取得したことがわかりました。ブランチの変更が変更された後、gitが変更されたと報告していたファイルが判明しました。（どうやらgitがCRLF行の終わりをファイルに正しく適用していなかったためと思われます。）

Windows用の最新の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つの可能性は、リポジトリー内のパッケージの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

うまくいきました！