Y a-t-il une différence entre "git reset --hard hash" et "git checkout hash" ?

Question

Alors que reset y checkout ont des usages différents la plupart du temps, je ne vois pas quelle différence il y a entre ces deux-là.

Il y en a probablement un, sinon personne n'aurait pris la peine d'ajouter une --hard option pour faire quelque chose de la base checkout peut faire.

Peut-être y a-t-il une différence dans la façon dont vous verrez l'histoire ?

Answer 1

Cette réponse est essentiellement tirée de ma réponse à une question précédente : La réinitialisation git en langage clair .

Les deux sont très différents. Ils aboutissent au même état pour votre index et votre arbre de travail, mais l'historique et la branche actuelle qui en résultent ne sont pas les mêmes.

Supposons que votre historique ressemble à ceci, avec la branche master actuellement extraite :

- A - B - C (HEAD, master)

et tu cours git reset --hard B . Vous obtiendrez ceci :

- A - B (HEAD, master)      # - C is still here, but there's no
                            # branch pointing to it anymore

Vous obtiendrez cet effet si vous utilisez --mixed o --soft aussi - la seule différence est ce qui arrive à votre arbre de travail et à votre index. Dans le --hard Dans ce cas, l'arbre de travail et l'index correspondent B .

Maintenant, supposons que vous couriez git checkout B à la place. Tu auras ça :

- A - B (HEAD) - C (master)

Vous vous êtes retrouvé dans un état d'HEAD détaché. HEAD l'arbre de travail, l'index de toutes les correspondances B comme pour le hard reset, mais la branche master a été laissée en place à l'adresse suivante C . Si vous faites un nouveau commit D à ce stade, vous obtiendrez ceci, qui n'est probablement pas ce que vous voulez :

- A - B - C (master)
       \
        D (HEAD)

Donc, vous utilisez checkout pour, eh bien, vérifier ce commit. Vous pouvez le modifier, faire ce que vous voulez, mais vous avez laissé votre branche derrière vous. Si vous voulez que la branche soit déplacée aussi, vous utilisez reset.

Answer 2

Si la documentation fournie avec Git ne vous aide pas, jetez un coup d'oeil à Une référence visuelle de Git par Mark Lodato.

En particulier, si vous comparez git checkout <non-branch> con git reset --hard <non-branch> (en lien direct) :

_{(source : <a href="http://marklodato.github.com/visual-git-guide/checkout-detached.svg.png" rel="nofollow noreferrer">github.com </a>)}

Notez que dans le cas de git reset --hard master~3 vous laissez derrière vous une partie du DAG de révisions - certains commits ne sont référencés par aucune branche. Ceux-ci sont protégés pendant (par défaut) 30 jours par la fonction reflog ; ils seraient finalement élagués (supprimés).

Answer 3

git-reset hash définit la référence de la branche au hachage donné, et éventuellement la vérifie, avec --hard .

git-checkout hash définit l'arbre de travail au hash donné ; et à moins que hash soit un nom de branche, vous vous retrouverez avec une tête détachée.

En fin de compte, git s'occupe de 3 choses :

                   working tree (your code)
-------------------------------------------------------------------------
                     index/staging-area
-------------------------------------------------------------------------
      repository (bunch of commits, trees, branch names, etc)

git-checkout par défaut ne met à jour que l'index et l'arbre de travail, et peut optionnellement mettre à jour quelque chose dans le référentiel (avec la commande -b option)

git-reset par défaut ne fait que mettre à jour le référentiel et l'index, et optionnellement l'arbre de travail (avec la commande --hard option)

Vous pouvez penser au dépôt comme ceci :

 HEAD -> master

 refs:
    master -> sha_of_commit_X
    dev -> sha_of_commit_Y

 objects: (addressed by sha1)

    sha_of_commit_X, sha_of_commit_Y, sha_of_commit_Z, sha_of_commit_A ....

git-reset manipule ce vers quoi pointent les références de la branche.

Supposons que votre histoire ressemble à ceci :

           T--S--R--Q [master][dev]
          / 
   A--B--C--D--E--F--G [topic1]
                   \
                    Z--Y--X--W [topic2][topic3]

Gardez à l'esprit que les branches sont juste des noms qui avancent automatiquement lorsque vous livrez.

Vous avez donc les branches suivantes :

 master -> Q
 dev -> Q
 topic1 -> G
 topic2 -> W
 topic3 -> W

Et votre branche actuelle est topic2 c'est-à-dire que le HEAD pointe vers le sujet 2.

HEAD -> topic2

Ensuite, git reset X réinitialisera le nom topic2 pour pointer vers X ; ce qui signifie que si vous faites un commit P sur la branche topic2, les choses ressembleront à ceci :

           T--S--R--Q [master][dev]
          / 
   A--B--C--D--E--F--G [topic1]
                   \
                    Z--Y--X--W [topic3]
                           \
                            P [topic2]