git tire du maître dans la twig de développement

J'ai une twig appelée dmgr2 (développement) et je veux tirer de la twig principale (site en direct) et incorporer tous les changements dans ma twig de développement. Y a-t-il une meilleure manière de faire cela? voici ce que j'avais prévu de faire:

git checkout dmgr2 git pull origin master 

Cela devrait amener les changements en direct dans ma twig de développement, ou est-ce que j'ai tort?

Solutions Collecting From Web of "git tire du maître dans la twig de développement"

Les étapes que vous avez listées fonctionneront, mais il y a un moyen plus long qui vous donne plus d'options:

 git checkout dmgr2 # gets you "on branch dmgr2" git fetch origin # gets you up to date with origin git merge origin/master 

La command fetch peut être effectuée à tout moment avant la merge , c'est-à-dire que vous pouvez inverser l'ordre de la récupération et de la command, car fetch va juste à la télécommand ( origin ) et lui dit: "donne-moi tout ce que Je ne fais pas ", c'est-à-dire, tous les commits sur toutes les twigs. Ils sont copiés dans votre référentiel, mais nommés origin/branch pour toute twig nommée branch sur la télécommand.

À ce stade, vous pouvez utiliser n'importe quelle visionneuse ( git log , gitk , etc) pour voir "ce qu'ils ont" que vous n'avez pas, et vice versa. Parfois cela n'est utile que pour les sentiments chauds et flous ("ah, oui, c'est en fait ce que je veux") et parfois c'est utile pour changer complètement de stratégie ("whoa, je ne veux pas encore ça").

Enfin, la command merge prend le commit donné, que vous pouvez nommer origin/master , et fait tout ce qu'il faut pour amener ce commit et ses ancêtres, à la twig sur laquelle vous êtes quand vous exécutez la merge . Vous pouvez insert --no-ff ou --ff-only pour empêcher une avance rapide, ou ne merge que si le résultat est une avance rapide, si vous le souhaitez.

Lorsque vous utilisez la séquence:

 git checkout dmgr2 git pull origin master 

la command pull request à git d'exécuter git fetch , puis l'équivalent moral de git merge origin/master . Donc, c'est presque la même chose que de faire les deux étapes à la main, mais il y a quelques différences subtiles qui ne vous préoccupent probablement pas trop. (En particulier, l'étape de fetch lancée par pull n'apporte que l' origin/master , et elle ne met pas à jour l'arbitre dans votre repo: 1 toutes les nouvelles FETCH_HEAD référencées que par la reference spéciale FETCH_HEAD .)

Si vous utilisez l' git fetch origin plus explicite (puis regardez autour), puis git merge origin/master sequence, vous pouvez également mettre votre propre master local à jour avec la télécommand, avec un seul fetch exécuté sur le réseau:

 git fetch origin git checkout master git merge --ff-only origin/master git checkout dmgr2 git merge --no-ff origin/master 

par exemple.


1 Cette deuxième partie a été modifiée – je dis «corrigé» – dans le git 1.8.4, qui met maintenant à jour les references de «twigment à distance» de manière opportuniste. (Comme l'indiquent les notes de publication, il est délibéré de ne pas tenir count de la mise à jour, mais il s'avère que plus de gens préfèrent que git le mette à jour. , et donc récupérable à partir du, reflog.Cela permet également une nouvelle fonctionnalité git 1.9 / 2.0 pour find des rebas en amont.)