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

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 bash

 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?

De la página de inicio de git reset :

 --hard Hace coincidir el tree de trabajo y el índice con el tree
                cambiado a.  Cualquier cambio en los files rastreados en el tree de trabajo desde
                <commit> están perdidos.

 --unir
               Restablece el índice para que coincida con el tree registrado por la confirmación nombrada, y
               actualiza los files que son diferentes entre la confirmación nombrada y
               el compromiso actual en el tree de trabajo.

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.

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 respuesta de manojlds , e ilustrado por la input del blog , este último es especialmente útil cuando ve un post 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 tree 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 twig mientras se fusiona, similar a lo que hace ' git checkout -m ' para mover HEAD .

Esto es útil cuando realiza una extracción con cambios en el tree 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 files 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.

Aparentemente de acuerdo a:

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

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

–merge – Restablece el índice para que coincida con el tree registrado por la confirmación nombrada y actualiza los files que son diferentes entre la confirmación nombrada y la confirmación actual en el tree de trabajo.