「git rm --cached x」と「git reset head-x」？
git rmは、ステージング領域からエントリを削除します。これは、ファイルの「ステージング解除」を行うgit reset HEADとは少し異なります。 「アンステージング」とは、ステージング領域を、変更を開始する前の状態に戻すことを意味します。一方、git rmは、ファイルをステージから完全にキックするため、次のコミットスナップショットには含まれないため、事実上削除されます。デフォルトでは、
git rm fileはファイルをステージング領域から完全に削除し、ディスク>（作業ディレクトリ）からも削除します。ファイルを作業ディレクトリに残すには、git rm --cachedを使用できます。
しかし、git rm --cached asdとgit reset head -- asdの違いは何ですか？
ファイルは、たとえば、ツリー、インデックス、作業コピーの3つの場所に配置できます。ファイルをフォルダーに追加するだけで、作業コピーに追加することになります。
git add fileのようなことをするとき、それをインデックスに追加します。そして、コミットすると、ツリーにも追加します。
Git resetでさらに一般的な3つのフラグを知るのに役立つでしょう。
git reset [--
<mode>] [<commit>]このフォームは、現在のブランチヘッドを
<commit>にリセットし、インデックスを更新（<commit>のツリーにリセット）し、<mode>に応じて作業ツリーを更新します。
-softインデックスファイルや作業ツリーにはまったく触れません（ただし、すべてのモードがそうであるように、頭部を
<commit>にリセットします）。これにより、変更されたすべてのファイルが「コミットされる変更」のままになります。これは、Gitのステータスに基づいています。-mixed
インデックスをリセットしますが、作業ツリーはリセットしません（つまり、変更したファイルは保存されますが、コミットのマークは付けられません）。更新されていないものを報告します。これがデフォルトのアクションです。
-hard
インデックスと作業ツリーをリセットします。
<commit>以降の作業ツリー内の追跡ファイルへの変更は破棄されます。
さて、あなたがgit reset HEADのようなことをすると-あなたが実際にやっていることはgit reset HEAD --mixedであり、ファイルの追加/インデックスへの変更の追加を開始する前の状態にインデックスを「リセット」します（git add経由）この場合、作業コピーとインデックス（またはステージング）は同期していましたが、リセット後にHEADとインデックスを同期させました。
一方、git rmは作業ディレクトリとインデックスからファイルを削除します。コミットすると、ファイルもツリーから削除されます。ただし、git rm --cachedはインデックスからのみファイルを削除し、作業コピーに保持します。これはgit add fileの正反対です。この場合、インデックスをHEADおよび作業と異なるものにし、その中でHEADファイルの以前にコミットされたバージョンがあり、作業コピーにファイルのHEADからのコンテンツまたはコンテンツがあり、インデックスからファイルを削除した場合、lasの変更があります。コミットによりインデックスとツリーが同期され、ファイルが削除されます。
おそらく例が役立ちます：
git rm --cached asd
git commit -m "the file asd is gone from the repository"
versus
git reset HEAD -- asd
git commit -m "the file asd remains in the repository"
elseを何も変更していない場合、2番目のコミットは実際には何もしません。
git rm --cached file will removeステージからのファイル。つまり、コミットするとファイルは削除されます。 git reset HEAD -- fileは、ステージング領域のファイルをHEADコミットの状態にリセットするだけです。つまり、最後にコミットしてから行った変更を元に戻します。その変更がファイルの新規追加である場合、それらは同等になります。