git reset vs git reset CABEZA

git-reset unstage

Question

Cada vez que se organiza un archivo, Git ofrece instrucciones útiles en caso de que necesite quitar la etapa de un archivo:

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

Sin embargo, los decentes Git Tutorials de Atlassian simplemente dicen:

git reset <file>

Esto parece más sencillo, entonces, ¿por qué la diferencia?

Answer 1

La primera vez, antes de cualquier commit, el HEAD no existe, entonces obtenemos:

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

Answer 2

No hay diferencia (desde la página de manual de git reset ) en términos del parámetro predeterminado:

El <tree-ish>/<commit> defecto es HEAD en todas sus formas.

Ese mensaje inicialmente no incluía HEAD: commit 3c1eb9c, enero de 2007, git 1.5.0-rc1 , pero como el valor predeterminado no siempre se conoce, el mensaje de ayuda deja en claro a qué commit se supone que debe restablecer.

HEAD aparece en commit 367c988, noviembre de 2007, Git 1.5.4 :

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

torek señala una diferencia real en los comentarios :

Al especificar HEAD , garantiza que la primera palabra después de HEAD se tome como nombre de ruta.
Por ejemplo, suponga que ejecuta git reset zorg . ¿Es zorg un árbol-ish, como un nombre de etiqueta, o es un nombre de ruta, ./zorg ?
La respuesta de Git es: es un árbol-ish si git rev-parse puede convertirlo en una ID de árbol, de lo contrario es un camino.
Puede escribir git reset -- zorg o git reset HEAD zorg para asegurarse de que git lo trate como una ruta.

Vea más sobre la sintaxis de doble guión ( -- ) en " Eliminar una rama git mal llamada ".

El agrega en los comentarios :

Como comentario aparte, lo sugieren para descartar cambios en el directorio de trabajo
(es decir, git checkout -- <file> ).
Simplemente parece inconsistente con git reset HEAD <file> .

Mientras que la página de manual de git reset indica claramente la falta de tree-ish en git reset <tree-ish> -- <paths> significa HEAD, no es así para git checkout <tree-ish> -- <paths> .

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

Cuando se dan <paths> , git checkout no cambia de rama.
Actualiza las rutas nombradas en el árbol de trabajo desde el archivo de índice o desde un <tree-ish> nombrado (la mayoría de las veces un commit).

Eso significa que git checkout -- path anulará el árbol de trabajo con lo que ya se ha organizado ( git add ''ed).
Mientras que git reset -- PATH (que es la forma mixta de git reset) restablecerá el índice con lo que HEAD contiene (eliminando efectivamente lo que se agregó)

git reset y git checkout no usan el mismo valor predeterminado y:

• puede representar el árbol predeterminado para git reset <tree-ish> <file> : HEAD .
  Por lo tanto, git reset HEAD <file> ;
• pero no puede representar el parámetro predeterminado cuando no proporciona un árbol para el git checkout : es el índice.
  Por lo tanto, git checkout -- file .

El -- tiene que usarse en el caso de git checkout , ya que solo hay un parámetro, y debe quedar claro que el parámetro representa archivos .

Tenga en cuenta que git checkout HEAD files es diferente: torek menciona en los comentarios

git checkout HEAD path Copias de git checkout HEAD path desde el commit HEAD (el árbol-ish) al índice y luego al directorio de trabajo.

Nota: con Git 2.23+, agosto de 2019, puede usar git restore lugar

Ver los ejemplos :

Para restaurar un archivo en el índice para que coincida con la versión en HEAD (esto es lo mismo que usar git-reset )

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

página man:

git restore --staged hello.c no especifica una fuente, y solo restaura el índice ( --staged ): lo hace (por defecto) usando HEAD como fuente.

Por defecto, las fuentes de restauración para el árbol de trabajo y el índice son el índice y HEAD respectivamente.
--source podría usarse para especificar una confirmación como la fuente de restauración.

Otros ejemplos:

Puede restaurar tanto el índice como el árbol de trabajo (esto es lo mismo que usar git-checkout )

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

o la forma corta que es más práctica pero menos legible:

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

git restore es un nombre de comando más natural y no tiene ambigüedad.

Answer 3

Por defecto, git reset es equivalente a git reset HEAD

Citando la página del manual (mi énfasis):

git-reset: restablece el HEAD actual al estado especificado.

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

En la primera y segunda forma, copie las entradas de <tree-ish> en el índice. En la tercera forma, configure el encabezado de rama actual (HEAD) en <commitir>, opcionalmente modificando el índice y el árbol de trabajo para que coincida. El <tree-ish> / <commit> por defecto es HEAD en todas sus formas.

[...]

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

Este formulario restablece las entradas de índice para todos los <paths> a su estado en <tree-ish>. (No afecta el árbol de trabajo o la rama actual).

Esto significa que git reset <paths> es lo opuesto a git add <paths> .

De esto ves que no hay una diferencia real en el comportamiento.

Esto parece más sencillo, entonces, ¿por qué la diferencia?

Como ambos son iguales, también podrías usar la versión más corta de los dos.