Quelle est la différence entre « git reset » et « git checkout »?
-
30-09-2019 - |
Question
J'ai toujours pensé git reset
et git checkout
comme le même, en ce sens que les deux apportent le dos de projet à un engagement spécifique. Cependant, je pense qu'ils ne peuvent pas être exactement la même chose, que ce serait redondant. Quelle est la différence réelle entre les deux? Je suis un peu confus, car le svn n'a que svn co
de revenir le commettras.
AJOUTÉE
VonC et Charles ont expliqué les différences entre git reset
et git checkout
vraiment bien. Ma compréhension actuelle est que git reset
Revient toutes les modifications à un engagement spécifique, alors que git checkout
plus ou moins se prépare à une branche. J'ai trouvé les deux schémas suivants tout à fait utiles pour en arriver à cette compréhension:
AJOUTÉE 3
http://think-like-a-git.net/sections/rebase-from-the-ground-up/using-git-cherry-pick-to-simulate-git-rebase .html , la caisse et la réinitialisation peuvent imiter le rebasage.
git checkout bar
git reset --hard newbar
git branch -d newbar
La solution
-
git reset
est spécifiquement sur les mise à jour de l'indice , déplacement de la tête. -
git checkout
est sur le point mise à jour de l'arbre de travail ( à l'indice ou l'arbre spécifié). Il mettra à jour la tête seulement si vous extrayez une branche (sinon, vous vous retrouvez avec un détaché HEAD).
(En fait, avec Git 2,23 Q3 2019, ce seragit restore
, pas nécessairementgit checkout
)
Par comparaison, puisque svn n'a pas d'index, seul un arbre de travail, svn checkout
copiera une révision donnée sur un répertoire distinct.
Le plus proche équivalent git checkout
serait:
-
svn update
(si vous êtes dans la même branche, ce qui signifie la même URL SVN) -
svn switch
(si vous passez commande, par exemple, la même branche, mais d'une autre URL SVN repo)
Tous ces trois modifications d'arbres de travail (svn checkout
, update
, switch
) ont une seule commande dans git:. git checkout
Mais depuis git a aussi la notion d'index (que « la mise en scène zone » entre le repo et l'arbre de travail), vous avez également git reset
.
Thinkeye mentionne dans les commentaires l'article " Réinitialiser démystifié".
Par exemple, si nous avons deux branches, «
master
» et «develop
» montrant différents commits, et nous sommes actuellement sur «develop
» (si les points de la tête pour lui) et nous couronsgit reset master
, lui-même «develop
» sera Orientez maintenant au même commit que «master
» fait.Par contre, si nous courons à la place
git checkout master
, «develop
» ne bouge pas,HEAD
lui-même.HEAD
va maintenant pointer vers «master
».Ainsi, dans les deux cas, nous nous dirigeons
HEAD
à un point de commettreA
, mais comment nous le faisons est très différent.reset
se déplacera les points deHEAD
branche à, caisse se déplace lui-mêmeHEAD
pour pointer vers une autre branche.
Sur ces points, bien que:
Larsh ajoute dans les commentaires:
Le premier paragraphe de cette réponse, cependant, est trompeur. «
git checkout
... mettra à jour la tête seulement si vous extrayez une branche (sinon, vous vous retrouvez avec une tête détachée) »
Pas vrai:git checkout
mettra à jour la tête, même si vous extrayez une commettras ce n'est pas une branche (et oui, vous vous retrouvez avec une tête détachée, mais il encore être mis à jour).git checkout a839e8f updates HEAD to point to commit a839e8f.
De Novo Souscrit dans des commentaires:
@LarsH est correcte.
La seconde balle a une idée fausse de ce que HEAD est mettra à jour la tête seulement si vous passez commande une branche.
HEAD va où que vous soyez, comme une ombre.
Vérification de certains non-ref branche (par exemple, une étiquette), ou un commit directement, se déplacera HEAD. tête individuelle ne signifie pas que vous avez détaché de la tête, cela signifie que la tête est détachée d'une ref branche, que vous pouvez le voir, par exemple,git log --pretty=format:"%d" -1
.
- Etats tête attachés commenceront par
(HEAD ->
,- détaché montrera encore
(HEAD
, mais pas une flèche à une branche ref.
Autres conseils
Dans leur forme, plus simple reset
remet à zéro l'index sans toucher l'arbre de travail, tout en checkout
change l'arbre de travail sans toucher l'index.
Remet l'index HEAD
match, arbre de travail laissé seul:
git reset
Conceptuellement, cette vérifie l'index dans l'arbre de travail. Pour obtenir de faire quoi que ce soit que vous devez utiliser -f
pour le forcer à écraser les changements locaux. Ceci est une mesure de sécurité pour vous assurer que la forme « sans argument » ne détruit pas:
git checkout
Une fois que vous commencez à ajouter des paramètres, il est vrai qu'il ya un certain chevauchement.
checkout
est habituellement utilisé avec une branche, étiquette ou commettre. Dans ce cas, il réinitialise HEAD
et l'indice du donné engagement ainsi que l'exécution de la caisse de l'indice dans l'arbre de travail.
En outre, si vous fournissez --hard
à reset
vous pouvez demander reset
remplacer l'arbre de travail ainsi que la réinitialisation de l'index.
Si vous avez une branche actuelle vérifié là-bas est un autre crucial entre reset
et checkout
lorsque vous fournissez une branche alternative ou engager. reset
va changer la branche actuelle à point sélectionné alors engager checkout
laissera la branche courante seule mais la caisse de la branche ou de commettre fourni à la place.
D'autres formes de reset
et commit
impliquent des chemins d'approvisionnement.
Si vous fournissez des chemins pour vous reset
ne peut pas fournir --hard
et reset
ne changera la version de l'index des chemins fournis à la version dans la fourni commit (ou HEAD
si vous ne spécifiez pas commettras a).
Si vous fournissez des chemins à checkout
, comme reset
il mettra à jour la version de l'index des chemins fournis pour correspondre à la fourni commit (ou HEAD
), mais il sera toujours la caisse de la version d'index des chemins fournis dans l'arbre de travail.
Un cas d'utilisation simple changement lorsque vous revenez:
1. Utilisez réinitialisée si vous souhaitez annuler la mise en scène d'un fichier modifié.
2. Utilisez votre commande si vous souhaitez annuler les modifications du fichier unstaged / s.
Atlassian nous donner une excellente explication sur reset git , git caisse et ainsi, git revert . Dans cet article, il est expliqué les différentes utilisations de ces commandes sur un différents niveaux - fichier, mis en scène et instantané commettre
.https://www.atlassian.com/git/ tutorials / réinitialisation de vérification-out et réverse
La principale différence en un mot est que reset
déplace la référence de la branche courante , tandis que checkout
n'a pas (il se déplace HEAD).
Comme le livre Pro Git explique sous Réinitialiser démystifié
La première
reset
chose va faire est Déplacer quels points HEAD . Ce n'est pas le même que changer HEAD lui-même (qui est ce quecheckout
fait);reset
déplace la branche que la tête pointe. Cela signifie que si la tête est ensemble à la branchemaster
(à savoir que vous êtes actuellement sur la branchemaster
), en cours d'exécutiongit reset 9e5e6a4
commencera en faisant le point demaster
à9e5e6a4
. [Italiques ajoutés]
Voir aussi la réponse de VonC un très utile et texte extrait diagramme du même article, que je ne vais pas faire double emploi ici.
Bien sûr, il y a beaucoup plus de détails sur ce que les effets checkout
et reset
peuvent avoir sur l'index et l'arbre de travail, en fonction de quels paramètres sont utilisés. Il peut y avoir beaucoup de similitudes et les différences entre les deux commandes. Mais comme je le vois, la plus grande différence cruciale est de savoir s'ils se déplacent la pointe de la branche actuelle.
Les deux commandes (RESET et la caisse) sont complètement différents.
checkout X
EST reset --hard X
Si X est un nom de branche,
checkout X
va changer la branche courante
tandis que reset --hard X
ne sera pas.