Git: git rebase sur la branche de développement de l'amont

Le plus simple (le plus évident pour tout le monde) la méthode consiste à mettre à jour votre master direction générale d'abord, puis de rebase sur la mise à jour master qui est maintenant exactement la même que origin/master:

$ git fetch origin                    # Get updates from remote.
$ git checkout master                 # Now bring master into sync:
$ git merge --ff-only origin/master   # if this fails you have stuff
                                      # in your master that they don't
                                      # have in theirs, and you need
                                      # to decide what to do about it

À ce stade, si tout s'est bien passé, master et origin/master sont les mêmes (comme vous pouvez le voir graphique téléspectateurs comme gitk, ou avec git log --graph --oneline --decorate), et il doit être clair comment git rebase master fonctionne.

Mais vous n'avez pas réellement le faire. Vous pouvez simplement git rebase origin/master, tout en étant sur develop. (Cela permettra de laisser votre master de l'onu-l'avant-ed—sans doute à un certain point, vous voulez en avant-ed—il n'est donc pas vraiment vous sauver beaucoup. Mais il est plus facile de le faire maintenant.)

---

La longue et ennuyeuse "pourquoi" de la partie: git rebase prend, dans sa forme longue, trois points de la documentation décrit comme newbase, upstream, et branch:

git rebase ... [--onto <newbase>] [<upstream>] [<branch>]

Si vous spécifiez exactement un argument, comme dans git rebase master, que les noms de la upstream et les deux newbase et branch sont calculées. Le branch est la branche courante (c'est à dire, HEAD, qui ne doit pas être détaché). Si vous omettez --onto, le newbase est pris comme le upstream argument. Donc, si vous êtes sur develop maintenant, et que vous exécutez git rebase X, le branch est develop et les deux newbase et upstream sont X.

Le rebase méthode est, en effet (il y a diverses optimisations internes et de l'effet sur le reflog est un peu différent):

1. découvrez branch
2. enregistrer une référence (ORIG_HEAD) pour l'engager à qui branch points
3. réinitialiser la git reset --hard) à newbase
4. pour tous s'engager dans upstream..ORIG_HEAD¹ (dans la plus ancienne à la plus récente commande), git cherry-pick qui s'engagent pour l'ajouter à la réinitialisation de la branche.

Ainsi, comme dans la documentation:

   Assume the following history exists and the current branch is "topic":

                 A---B---C  HEAD=topic
                /
           D---E---F---G    master

lorsque vous git rebase master, vous bénéficiez de:

                   A---B---C         ORIG_HEAD
                  /
                 /      A'--B'--C'  HEAD=topic
                /      /
           D---E---F---G             master

(tout ce que je fait ici est de prendre l'exemple de la page de man et ajouter le ORIG_HEAD de l'étiquette et de la HEAD=, pour montrer qu'à l'origine, les commits sont "toujours là", et que HEAD est une référence à topic).

Alors, qu'advient-il si vous avez votre develop et master et ils ont leur master qui a un peu plus de changements? Mettons que:

A -- B -- C                         master
          | \
          |   D                     origin/master
          |
          E -- F                    HEAD=develop

Maintenant, vous git rebase origin/master:

A -- B -- C                         master
          | \
          |   D                     origin/master
          |     \
          |       E' -- F'          HEAD=develop
          |
          E -- F                    ORIG_HEAD

À un certain point, vous passer votre propre master au point de commettre D trop (et vous le déposez ORIG_HEAD):

A -- B -- C -- D                    master, origin/master
                 \
                   E' - F'          HEAD=develop

qui est la même chose avec certains des étiquettes déplaçables.

C'est tout ce que la direction générale des étiquettes, ils sont de simples étiquettes. Chaque étiquette points à une (seule) s'engager. Le s'engage point de retour à la précédente s'engage, qui est ce qui construit la validation de l'arbre (ou "commettre des DAG", vraiment).

---

¹Git's X..Y syntaxe cache beaucoup de "profondeur de la magie". Il signifie "tous les commits accessible à partir de l'étiquette Y qui ne sont pas accessibles à partir de l'étiquette X. Ce qui est exactement l'ensemble de commits qui ont besoin d'être cerises cueillies, comme ceux qui sont les commits qui ont été sur branch, et n'étaient pas sur upstream, avant la "rebase" op. Il "ressemble à" un temps de base de la séquence, à première vue, et qui fonctionne, en général, dans la tête des gens, mais il est basé sur la validation graphique de la topologie. Parfois, cela les voyages des gens bien: A..B, où A n'est pas liée à B à tous (à cause des multiples commettre des arbres dans le repo), signifie "chaque révision, accessible à partir de B.

OriginalL'auteur torek