¿Cuál es la diferencia entre `git reset –hard master` y` git reset –hard origin / master`?

Intenté muchos enlaces en Stackoverflow / en otro lugar para comprender correctamente el comportamiento de

git reset --hard option

Yo sé eso:

  • Si se omite o si es de origin , el restablecimiento se realiza en la confirmación más reciente sobre el origin
  • Si se proporciona un hash SHA1, el restablecimiento se realiza en la confirmación correspondiente.

Lo que no entiendo son los siguientes valores:

  1. origin
  2. HEAD
  3. origin/master
  4. origin/branch

Todos parecen tener el mismo comportamiento, es decir, un punto a la última confirmación en el master .

Por favor explique cuál es el significado de la opción de 4 valores proporcionada anteriormente.

También me gustaría saber si estoy en una twig específica, ¿cómo puedo restablecer el último compromiso en esa misma twig? Si, por ejemplo, estoy en v1.2 , origin/v1.2 todavía me lleva a la última confirmación en el master .

En primer lugar, debe comprender que los nombres de las twigs y las tags son simplemente pointers a los valores hash, que representan una única confirmación, si dice que hay 4 opciones que tienen el mismo comportamiento, entonces la primera respuesta lógica es porque todos apuntan a la mismo compromiso

  • origin No estoy seguro de esto, pero creo que el origin por sí mismo se resolverá en origin/HEAD que creo que dependerá de la configuration github, en github establecer una 'twig pnetworkingeterminada', el origin/head se resolverá en origin/[default_branch] , en su caso estoy asumiendo que es maestro, por eso tiene el mismo efecto que el de origin/master .

  • HEAD siempre apunta a la confirmación actual, en la que está parado, por lo que se git reset --hard HEAD eliminará permanentemente todos los cambios en los files rastreados y los cambios en los files por etapas, pero no cambiará el hash de confirmación.

  • origin/master es la última confirmación en la twig maestra remota desde su última extracción / extracción, cada vez que se compromete a master , su master local se actualiza y su origin/master se actualiza, si alguien más empuja para master su informe no tendrá idea de que hay una actualización, a less que hagas una git fetch entonces tu origin/master se moverá por delante de tu master o incluso divergirá.
    ejecutar un git reset --hard origin/master tendrá el mismo efecto si actualmente se encuentra en la twig master y el master está sincronizado con el origin/master

  • origin/branch No estoy seguro de lo que esto representa, porque no hay origin/branch por defecto, así que supongo que creaste una twig llamada branch y que está en el mismo compromiso que tu maestro, para confirmar que puedes intentar hacer una git branch para ver todas tus twigs, supongo que encontrarás una branch llamada

Para ver todo esto de una manera visual, podrías intentar ejecutar git log --graph --decorate --all o prefiero una herramienta visual como gitk , si tienes el binary instalado, ejecutarías gitk --all para ver todas las twigs en relación el uno con el otro

master , HEAD , origin/something y tal vez alguna label, por qué no, todos pueden apuntar a la misma confirmación, pero definitivamente no son la misma cosa.

origin es generalmente el nombre de un repository remoto .

Puede ver sus controles remotos y configurar nuevos con git remote -v .

Pruébalo (con -v ) y probablemente tenga sentido.

remote/somebranch señala al jefe de alguna twig en un repository remoto.

origin/master apunta al jefe del master en origin .

¿Es lo mismo que master ?

Si y no. Si extraes tu twig principal, trabajas un poco y, mientras tanto, alguien más se compromete con el master y empuja hacia el origin , serán diferentes.

Cuando haces un git fetch origin , entonces, el origin/master tendrá confirmaciones adicionales (estará adelante ).

HEAD es simplemente "el compromiso actual". Piénsalo como . .

Ver esta pregunta

Nuevamente, esto podría ser lo mismo que master , pero si revisas otra twig o cometes o estás en medio de una rebase, bueno, no es así.

Así que intente esto en un nuevo repository en el que nadie más está trabajando:

 $ git checkout master $ git log -1 --format="%H" HEAD 123abc $ git log -1 --format="%H" origin/master 123abc 

¡Ellos son lo mismo!

 $ git diff origin/master 

Por supuesto, su contenido es el mismo.

 $ echo "foo" > foo $ git add foo $ git commit -m "Foo the thingy" $ git log -1 --format="%H" HEAD 321bca $ git log -1 --format="%H" origin/master 123abc 

Ah, mira, ¡ahora son compromisos diferentes!

 $ git push origin master $ git log -1 --format="%H" HEAD 321bca $ git log -1 --format="%H" origin/master 321bca 

¡Y ahora no lo son! hemos impulsado nuestro compromiso más reciente y ambos apuntan a lo mismo.

 $ git checkout -b newbranch $ echo "baz" > baz $ git add baz $ git commit -m "Baz the thingy with the stuff" $ git branch -a master * new_branch origin/master $ git log -1 --format="%H" 789def $ git log -1 --format="%H" master 321bca git log -1 --format="%H" origin/master 321bca git log -1 --format="%H" origin/new_branch unknown revision or path not in the working tree. 

Por supuesto no. No hemos empujado new_branch al origin , solo está en nuestra máquina local

 git checkout 123abc 

Acabamos de revisar 123abc , el viejo jefe de master . Ahora no es la cabeza de ninguna twig, pero podemos verificarlo de la misma manera.

 Note: checking out 123abc. You are in 'detached HEAD' state, etc $ git checkout -b old_master $ git branch -a master * new_branch origin/master old_master 

Ahora adivina cuál será su SHA1 respectivamente?