origin - Cuál es la diferencia entre el restablecimiento de git--hard y git reset--merge

git reset--hard

Question

En mis experimentos no he podido encontrar ninguna diferencia funcional entre

git reset --hard

y

git reset --merge

Las instrucciones de uso tampoco dan ninguna pista

--hard                reset HEAD, index and working tree
--merge               reset HEAD, index and working tree

Regularmente uso la opción --hard para entender cómo funciona. ¿Cuál es la diferencia entre las opciones --merge y --hard ?

Saludos, Olly

Tal vez un ejemplo sería útil aquí, usemos la siguiente secuencia:

cd git_repo
touch file_one
git add file_one
git commit -m "commit one" # sha1 of 123abc
echo "one" >> ./file_one
git commit -a -m "commit two" # sha1 of 234bcd
echo "two" >> ./file_one
git add . # populate index with a change
echo "three" >> ./file_one # populate working area with a change

Ahora si lo intento

git reset --merge 123abc

yo obtengo

error: Entry ''file_one'' not uptodate. Cannot merge.
fatal: Could not reset index file to revision ''123abc''

la razón es que file_one tiene cambios tanto en el área de trabajo como en el índice

Para remediar esto lo hago

git add .
git reset --merge 123abc

Esta vez funciona, sin embargo, obtengo el mismo resultado que git reset --hard . El índice está vacío, el área de trabajo está vacía, file_one está vacío, como estaba después del primer commit.

¿Alguien puede presentar los pasos que ilustran la diferencia?

Answer 1

Aparentemente de acuerdo a:

http://www.kernel.org/pub/software/scm/git/docs/git-reset.html

--hard - Coincide con el árbol de trabajo y el índice con el del árbol al que se está cambiando. Cualquier cambio en los archivos rastreados en el árbol de trabajo desde <commit> se pierde.

--merge - Restablece el índice para que coincida con el árbol registrado por la confirmación nombrada y actualiza los archivos que son diferentes entre la confirmación nombrada y la confirmación actual en el árbol de trabajo.

Answer 2

De la página de inicio de git reset :

--hard Matches the working tree and index to that of the tree being switched to. Any changes to tracked files in the working tree since <commit> are lost. --merge Resets the index to match the tree recorded by the named commit, and updates the files that are different between the named commit and the current commit in the working tree.

El git reset --merge está destinado a ser una versión más segura de la git reset --hard de git reset --hard , cuando los cambios y los cambios de alguien más se mezclan, tratando de llevar a cabo nuestros cambios.

Answer 3

El artículo " Git undo, reset or revert? " Resume los diferentes usos, cuando se usa con ORIG_HEAD :

# Reset the latest successful pull or merge
$ git reset --hard ORIG_HEAD

# Reset the latest pull or merge, into a dirty working tree
$ git reset --merge ORIG_HEAD

Como se menciona en la answer manojlds , e ilustrado por la entrada del blog , este último es especialmente útil cuando ve un mensaje de error como:

fatal: You have not concluded your merge. (`MERGE_HEAD` exists)

El hilo " [PATCH] se niega a fusionarse durante una fusión " también detalla ese punto:

git reset --merge HEAD

Llena el caso bastante diferente en el que realizó una fusión limpia con algunos cambios no confirmados en el árbol de trabajo, pero luego desea descartar la fusión nuevamente sin perder los cambios no confirmados.
En ausencia de los cambios, simplemente usaría --hard , pero aquí quiere mover la punta de la rama mientras se fusiona, similar a lo que hace '' git checkout -m '' para mover HEAD .

Answer 4

Esto es útil cuando realiza una extracción con cambios en el árbol de trabajo, y encuentra que la fusión no es la esperada (es posible que haya estado esperando que las confirmaciones no afecten a los archivos en los que estaba trabajando). En este punto, si git reset --hard ORIG_HEAD , git reset --hard ORIG_HEAD todo, incluso tus cambios locales. Si haces git reset --merge ORIG_HEAD , mantendrás tus cambios locales.