Git: mise à jour d'un référentiel de révision

Il n'y a pas de "mise à jour d'un référentiel vers une certaine version". Vous référentiel a toutes les versions, c'est ce que git fetch /git pull.

Si vous voulez mettre une révision spécifique de l'opération dans votre travail actuel arbre localement, il y a plusieurs façons de le faire. Le plus proche à vos questions est:

mise à jour de votre référentiel local:

git fetch origin

créer une nouvelle branche (quelle qu'en soit la direction générale vous êtes actuellement sur, nous allons réinitialiser dur, plus tard, de sorte qu'il n'a pas d'importance):

git branch yourbranchname
git checkout yourbranchname

Ci-dessus 2 opérations peut être abrégé en un seul (l'actuel CHEF est considéré comme la source de la branche):

git checkout -b yourbranchname

puis placez le pointeur de la branche pour la livraison vous avez besoin (B):

git reset --hard sha1-of-B

git reset --hard fonctionnera toujours, il ne dépend pas de votre direction générale de l'histoire, la seule condition pour que cela fonctionne est que commettre B est en local sur l'objet de base (c'est à dire B doit exister et doit avoir été récupéré à partir d'une distance repo est qu'il n'est pas votre travail).

@Hasturkun points, vous pouvez aussi passer directement de l'arbitraire de hachage avec un argument supplémentaire:

git checkout -b yourbranchname SHA-1

OriginalL'auteur Sébastien Dawans

Votre approche est tout à fait faux. Vous êtes en train de modifier quelque chose que vous ne voulez pas modifier: Votre branche courante (sans doute master).

Simple, linéaire dépôt git est une chaîne de commits comme ce

*---A---*---*---B---*---*---C
    ^                       ^
    |                       |
  master              origin/master
    ^
    |
   HEAD

Qui est l'état de votre dépôt après avoir appelé git fetch. Noter que la totalité de l'histoire avec toutes ses étapes intermédiaires est là, sur votre disque dur local. C'est juste que vous n'avez que l'état à s'engager A vérifié (HEAD points de master qui points à A), de sorte que les fichiers que vous voyez appartiennent à cet état.

Maintenant, si vous voulez juste regarder l'état qui a commis comme B, vous pouvez simplement vérifier que s'engager avec git checkout B. Cela met à jour les fichiers que vous voyez à l'état de B, et les points de HEAD à ce commit:

*---A---*---*---B---*---*---C
    ^           ^           ^
    |           |           |
  master       HEAD   origin/master

HEAD toujours les références de la validation ou de la direction que git pense que vous êtes sur, et à qui il permettra de comparer votre répertoire de travail lorsque vous appelez git status.

La simple git checkout B est suffisant, si vous voulez juste regarder ce commit. Si vous souhaitez apporter des modifications que vous vous engagez et que vous souhaitez conserver, vous devez introduire une nouvelle branche pour enregistrer ces modifications. Ceci est réalisé par un simple git checkout -b newBranch après la git checkout B. Cela vous donnera l'état

*---A---*---*---B---*---*---C
    ^           ^           ^
    |           |           |
  master    newBranch origin/master
                ^
                |
               HEAD

Cela donne juste un nom pour commettre B autre que sa valeur de hachage. Après quelques engage, votre état pourrait ressembler à ceci:

*---A---*---*---B---*---*---C
    ^           |           ^
    |           |           |
  master         \    origin/master
                   \
                    *---*---D
                            ^
                            |
                        newBranch
                            ^
                            |
                           HEAD

Le point est, que, après vérification de certaines autres branches/s'engager avec git checkout ..., vous pouvez toujours revenir facilement à s'engager D en appelant git checkout newBranch, et la référence permanente s'arrête git de la collecte des ordures s'engager D.

---

Maintenant, pourquoi est-à l'aide de git reset --hard mauvais? Tout d'abord, il clobbers tous vos changements locaux que vous n'avez pas commis mais sans autre avis. Deuxièmement, il peut perdre dans l'histoire, si vous n'êtes pas prudent avec elle.

Considérons, par exemple, le cas que vous avez fait quelques changements après la dernière poussé à vos amont de référentiel, et que vous voulez prendre un coup d'oeil à l'histoire commettre B. (Un peu l'inverse de l'affaire dans votre question.) L'histoire ressemble à ceci:

  *---A---*---*---B---*---*---C
      ^                       ^
      |                       |
origin/master               master
                              ^
                              |
                             HEAD

Avec git reset --hard B, vous obtenez cet état:

  *---A---*---*---B-(-*---*---C )
      ^           ^
      |           |
origin/master   master
                  ^
                  |
                 HEAD

Les commits entre parenthèses ne sont pas référencées directement ou indirectement par toute la branche, et de plus, peut-être nettoyés de tout temps. git peut ne pas être très agressif avec les ordures ménagères, la collecte, mais si c'est le garbage recueillons lorsque vous êtes dans cet état, il n'existe aucun moyen pour vous de vous engager C de retour, il sera perdu à jamais. Vous ne voulez pas que cela arrive, il n'est donc pas une bonne idée de prendre l'habitude d'utiliser git reset --hard à la légère.

Aviez-vous utilisé git checkout au lieu de cela, la direction de la master serait encore pointer à C, et vous devriez toujours être en mesure de les récupérer à l'aide d'un simple git checkout master.

OriginalL'auteur cmaster