git reset vs git reset CABEÇA

Toda vez que um arquivo foi preparado, o Git oferece instruções úteis no caso de você precisar desassociar um arquivo:

(use "git reset HEAD ..." to unstage)

No entanto, os decentes Git Tutorials da Atlassian dizem simplesmente:

git reset

Isso parece mais simples, então por que a diferença?

Nenhuma diferença (da página man git reset ) no termo do parâmetro padrão:

O / padronizado como HEAD em todos os formulários.

Inicialmente, essa mensagem não incluía HEAD: commit 3c1eb9c, janeiro de 2007, git 1.5.0-rc1 , mas como o padrão nem sempre é conhecido, a mensagem de ajuda deixa claro para qual commit você deve reinicializar.

HEAD aparece no commit 367c988, novembro de 2007, Git 1.5.4 :

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

torek aponta uma diferença real nos comentários :

Ao especificar HEAD , você garante que a primeira palavra após HEAD seja tomada como um nome de caminho.
Por exemplo, suponha que você execute o git reset zorg . É zorg um tree-ish, como um nome de tag, ou é um nome de caminho, ./zorg ?
A resposta do Git é: é um tree-ish se o git rev-parse puder transformá-lo em um ID de tree, caso contrário, é um caminho.
Você pode escrever git reset -- zorg ou git reset HEAD zorg para ter certeza que o git o trata como um caminho.

Veja mais sobre a syntax do hífen duplo ( -- ) em ” Excluindo uma ramificação git mal nomeada “.




O skube OP adiciona nos comentários :

Como um aparte, eles sugerem isso para descartar as mudanças no diretório de trabalho
(isto é, git checkout -- ).
Parece inconsistente com o git reset HEAD .

Enquanto git reset man page indica claramente a falta de tree-ish no git reset -- significa HEAD, não é assim para git checkout -- .

 git checkout  --  

Quando é dado, o git checkout não troca de branches.
Ele atualiza os caminhos nomeados na tree de trabalho do arquivo de índice ou de um nomeado (na maioria das vezes uma confirmação).

Isso significa git checkout -- path irá sobrescrever a tree de trabalho com o que já foi testado ( git add ‘ed).
Enquanto git reset -- PATH (sendo a forma mista de git reset) irá redefinir o índice com o que o HEAD contém (efetivamente descodificando o que foi adicionado)

git reset e git checkout não usam o mesmo padrão e:

  • você pode representar a tree padrão para git reset : HEAD .
    Daí git reset HEAD ;
  • mas você não pode representar o parâmetro padrão quando você não fornece uma tree para git checkout : é o índice.
    Daí git checkout -- file .

O -- tem que ser usado no caso do git checkout do git checkout , uma vez que existe apenas um parâmetro, e precisa ficar claro que o parâmetro representa os arquivos .

Note que os git checkout HEAD files são diferentes: torek menciona nos comentários

git checkout HEAD path copia do HEAD commit (o tree-ish) para o índice e depois para o diretório de trabalho.

Por padrão, git reset é equivalente a git reset HEAD

Citando a man page (minha ênfase):

git-reset – Redefine a CABEÇA atual para o estado especificado.

 git reset [-q] [] [--] … git reset (--patch | -p) [] [--] […​] git reset [--soft | --mixed [-N] | --hard | --merge | --keep] [-q] [] 

No primeiro e segundo formulário, copie as inputs de para o índice. Na terceira forma, defina a cabeça de ramificação atual (HEAD) para , opcionalmente modificando o índice e a tree de trabalho para corresponder. O / é padronizado como HEAD em todos os formulários.

[…]

 git reset [-q] [] [--] …​ 

Este formulário redefine as inputs de índice para todos os para seu estado em . (Isso não afeta a tree de trabalho ou o ramo atual.)

Isso significa que git reset é o oposto de git add .

A partir disso, você vê que não há diferença real no comportamento.

Isso parece mais simples, então por que a diferença?

Como ambos são iguais, é melhor usar a versão mais curta dos dois.

Primeira vez, antes de qualquer commit, o HEAD não existe, então nós temos:

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