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それをインデックスに追加します。そして、それをコミットすると、それもツリーに追加されます。
おそらく、次の3つの一般的なフラグを知るのに役立ちますgit reset。
git reset [-
<mode>] [<commit>]このフォームは、現在のブランチヘッドをにリセットし
<commit>、場合によってはインデックス（のツリーにリセット<commit>）と、に応じて作業ツリーを更新します<mode>。これは、次のいずれかである必要があります
。--softインデックスファイルにも作業ツリーにもまったく触れません（ただし、
<commit>すべてのモードと同様に、ヘッドをにリセットします）。これにより、git statusが示すように、変更されたすべてのファイルが「コミットされる変更」のままになります。-混合
インデックスをリセットしますが、作業ツリーはリセットしません（つまり、変更されたファイルは保持されますが、コミットのマークは付けられません）。更新されていないものを報告します。これがデフォルトのアクションです。
- 難しい
インデックスと作業ツリーをリセットします。作業ツリー内の追跡されたファイルへの変更はすべて
<commit>破棄されます。
さて、のようなgit reset HEADことをすると、実際に行っているのはgit reset HEAD --mixed、ファイルの追加/インデックスへの変更の追加を開始する前の状態にインデックスを「リセット」することです（を介してgit add）。この場合、作業コピーの状態に関係なく、それを1ビット変更しませんでしたが、ツリーのHEADと同期するようにインデックスを変更しました。以前にコミットされたが変更されたファイルをステージングするために使用されたかgit add、新しい（以前は追跡されていない）ファイルを追加するために使用されたかはgit reset HEAD、の正反対ですgit add。
git rm一方、作業ディレクトリとインデックスからファイルを削除し、コミットすると、ファイルもツリーから削除されます。git rm --cachedただし、ファイルはインデックスのみから削除され、作業コピーに保持されます。この場合、ファイルが以前にコミットされていれば、インデックスをツリーのHEADおよび作業コピーとは異なるものにしたため、HEADには以前にコミットされたバージョンのファイルがあり、インデックスにはファイルがありません。すべてであり、作業コピーには最後の変更が含まれています。コミットすると、インデックスとツリーが同期され、ファイルがツリーから削除されます（作業コピーでは追跡されないままになります）。新しい（以前は追跡されていなかった）ファイルを追加するために使用された場合、git addgit rm --cachedは正反対ですgit add（そして）とほとんど同じですgit reset HEAD。
Git 2.25では、これらのケースに新しいコマンドが導入されましたgit restoreが、Git 2.28の時点では、動作が変わる可能性があるという意味で、マニュアルページに「実験的」と記載されています。