「git rm --cached x」対「git reset head-x」？

GitRef.org-基本：

git rmステージング領域からエントリを削除します。これは、git reset HEADファイルの「ステージング解除」とは少し異なります。「アンステージ」とは、ステージング領域を、変更を加える前の状態に戻すことを意味します。 git rm一方、ファイルを完全にステージから外し、次のコミットスナップショットに含まれないようにすることで、ファイルを効果的に削除します。

デフォルトでは、a 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>、すべてのモードと同様に、ヘッドをにリセットします）。これにより、変更されたすべてのファイルが「コミットされる変更」のままになります。

-混合

インデックスをリセットしますが、作業ツリーはリセットしません（つまり、変更されたファイルは保持されますが、コミットのマークは付けられません）。更新されていないものを報告します。これがデフォルトのアクションです。

- ハード

インデックスと作業ツリーをリセットします。以降の作業ツリーで追跡されているファイルへの変更<commit>は破棄されます。

さて、あなたのような何かをするときgit reset HEAD-あなたが実際にやっていることでgit reset HEAD --mixedあり、それはあなたが（を経由してインデックスに変更を加える/ファイルの追加を開始する前にそれがあった状態にインデックス「リセット」されますgit add）この場合、作業コピーとではインデックス（またはステージング）は同期していましたが、リセット後にHEADとインデックスを同期させました。

git rm一方、作業ディレクトリとインデックスからファイルを削除し、コミットすると、ファイルもツリーから削除されます。git rm --cachedただし、ファイルはインデックスからのみ削除され、作業コピーに保持されます。これは、この場合とは正反対ですgit add file 。この場合、HEADおよび作業中とは異なるインデックスを作成し、HEADには以前にコミットされたバージョンのファイルがあり、作業コピーには、HEADのコンテンツまたはファイルとインデックスからファイルを削除した。コミットすると、インデックスとツリーが同期され、ファイルが削除されます。

おそらく例が役立つでしょう：

git rm --cached asd
git commit -m "the file asd is gone from the repository"

対

git reset HEAD -- asd
git commit -m "the file asd remains in the repository"

他に何も変更していない場合、2番目のコミットは実際には何もしません。

git rm --cached fileステージからファイルが削除されます。つまり、コミットするとファイルが削除されます。git reset HEAD -- fileステージング領域のファイルを単にHEADコミット時の状態にリセットします。つまり、前回のコミット以降に行った変更を元に戻します。その変更がたまたまファイルを新しく追加している場合、それらは同等です。