git reset против Git reset HEAD

Question

Каждый раз, когда файл создается, Git предлагает полезные инструкции на случай, если вам нужно удалить файл:

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

Однако приличные уроки по Git от Atlassian просто говорят:

git reset <file>

Это кажется более простым, так почему же разница?

Answer 1

Нет разницы (от git reset man страница) в терминах параметра по умолчанию:

<tree-ish>/<commit> по умолчанию HEAD во всех формах.

Изначально это сообщение не содержало HEAD: commit 3c1eb9c, январь 2007 г., git 1.5.0-rc1, но, поскольку значение по умолчанию не всегда известно, справочное сообщение дает понять, какой коммит вы должны сбросить.

HEAD появляется в коммите 367c988, ноябрь 2007 г., Git 1.5.4:

# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)

---

torek указывает на реальную разницу в комментариях:

Указав HEAD Вы гарантируете, что первое слово после HEAD берется в качестве имени пути.
Например, предположим, что вы запускаете git reset zorg, Является zorg древовидная структура, такая как имя тега, или это путь, ./zorg?
Git ответ: это дерево, если git rev-parse может превратить его в идентификатор дерева, в противном случае это путь.
Вы можете написать git reset -- zorg или же git reset HEAD zorg чтобы убедиться, что git рассматривает это как путь.

Подробнее о синтаксисе двойных дефисов (--) в разделе " Удаление ветки git с плохим именем ".

---

---

---

skube добавляет в комментариях:

Кроме того, они предлагают это для отмены изменений в рабочем каталоге
(т.е. git checkout -- <file>).
Это просто кажется несовместимым с git reset HEAD <file>,

В то время как git reset Страница man ясно указывает на отсутствие дерева в git reset <tree-ish> -- <paths> значит ГОЛОВА, это не так для git checkout <tree-ish> -- <paths>,

git checkout <tree-ish> -- <pathspec>

когда <paths> дано, git checkout не переключает ветки.
Он обновляет именованные пути в рабочем дереве из файла индекса или из именованного <tree-ish> (чаще всего коммит).

Это означает git checkout -- path переопределит рабочее дерево тем, что уже было подготовлено (git add "Под ред).
В то время как git reset -- PATH (будучи смешанной формой сброса git) будет сбрасывать индекс с тем, что содержит HEAD (фактически без добавления того, что было добавлено)

git reset а также git checkout не используйте то же самое по умолчанию, и:

• Вы можете представить дерево по умолчанию для git reset <tree-ish> <file>: HEAD,
  следовательно git reset HEAD <file>;
• но вы не можете представить параметр по умолчанию, если вы не предоставляете дерево для git checkout: это индекс.
  следовательно git checkout -- file,

-- должен быть использован в git checkout случай, так как есть только один параметр, и должно быть ясно, что параметр представляет файлы.

Обратите внимание, что git checkout HEAD files отличается: torek упоминает в комментариях

git checkout HEAD path копии с HEAD commit (tree-ish) в индекс и затем в рабочий каталог.

Answer 2

По умолчанию, git reset эквивалентно git reset HEAD

Цитирую справочную страницу (мой акцент):

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>]

В первой и второй форме скопируйте записи из в индекс. В третьей форме установите текущий заголовок ветви (HEAD) на , при необходимости изменив индекс и рабочее дерево для соответствия. / по умолчанию равен HEAD во всех формах.

[...]

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

Эта форма сбрасывает записи индекса для всех <путей> в их состояние в . (Это не влияет на рабочее дерево или текущую ветвь.)

Это означает, что git reset <paths> противоположность git add <paths> ,

Из этого вы видите, что нет реальной разницы в поведении.

Это кажется более простым, так почему же разница?

Поскольку они оба одинаковы, вы можете использовать самую короткую версию из двух.

Answer 3

В первый раз, перед тем как коммитов HEAD не существует, мы получаем:

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