web-dev-qa-db-ja.com

gitリセットvs gitリセットHEAD

ファイルがステージングされるたびに、Gitはファイルのステージングを解除する必要がある場合に役立つ指示を提供します。

(use "git reset HEAD <file>..." to unstage)

ただし、適切な AtlassianによるGitチュートリアル は、単に次のように言います。

git reset <file>

これはもっと簡単に思えますが、なぜ違いがあるのですか？

gitgit-resetunstage
18
skube

デフォルトでは、git resetはgit reset HEADと同等です。

Manページの引用（私の強調）：

git-reset-現在のHEADを指定された状態にリセットします。

git reset [-q] [<tree-ish>] [--] <paths>…
git reset (--patch | -p) [<tree-ish>] [--] [<paths>…​]
git reset [--soft | --mixed [-N] | --hard | --merge | --keep] [-q] [<commit>]

最初と2番目の形式で、<tree-ish>からインデックスにエントリをコピーします。 3番目の形式で、現在のブランチヘッド（HEAD）を<commit>に設定します。オプションで、インデックスと作業ツリーを一致するように変更します。 <tree-ish>/<commit>のデフォルトはHEAD）です。

[...]

git reset [-q] [<tree-ish>] [--] <paths>…​

このフォームは、すべての<paths>のインデックスエントリを<tree-ish>の状態にリセットします。 （作業ツリーや現在のブランチには影響しません。）

これは、git reset <paths>がgit add <paths>の反対であることを意味します。

これから、実際の動作に違いはないことがわかります。

これはもっと簡単に思えますが、なぜ違いがあるのですか？

どちらも同じなので、2つの最短バージョンを使用することもできます。

2
code_dredd

初めて、コミットする前にHEADが存在しない場合、次のようになります。

$git reset HEAD stagedFile
fatal: ambiguous argument 'HEAD': unknown revision or path not in the working tree
1
Grzegorz Kowalski