web-dev-qa-db-fra.com

git pull de master dans la branche de développement

J'ai une branche appelée dmgr2 (développement) et je souhaite retirer de la branche principale (site actif) et intégrer tous les changements à ma branche de développement. Y a-t-il une meilleure manière de faire cela? voici ce que j'avais prévu de faire, après avoir apporté des modifications:

git checkout dmgr2
git pull Origin master

cela devrait intégrer les changements en direct dans ma branche de développement, ou est-ce que je me trompe?

gitbranchpull
352
Matthew Colley

Les étapes que vous avez énumérées fonctionneront, mais il existe 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 commande fetch peut être exécutée n'importe où avant merge, c’est-à-dire que vous pouvez permuter l’ordre de récupération et de sortie, car fetch passe simplement à la télécommande nommée (Origin) et lui dit: "donnez-moi tout ce que vous avez Je ne le fais pas ", c’est-à-dire que tous s’engagent dans toutes les branches. Ils sont copiés dans votre référentiel, mais nommés Origin/branch pour toute branche nommée branch sur la télécommande.

À ce stade, vous pouvez utiliser n’importe quel lecteur (git log, gitk, etc.) pour voir «ce qu’ils ont», ce que vous n’aurez pas, et inversement. Parfois, cela n’est utile que pour Warm Fuzzy Feelings ("ah, oui, c’est en fait ce que je veux") et parfois, utile pour changer complètement de stratégie ("whoa, je ne veux pas CELA pour le moment").

Enfin, la commande merge prend le commit donné, que vous pouvez nommer Origin/master, et fait le nécessaire pour importer ce commit et ses ancêtres dans la branche sur laquelle vous vous trouvez lorsque vous exécutez merge. Vous pouvez insérer --no-ff ou --ff-only pour empêcher une avance rapide ou ne fusionner 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 commande pull demande à git d'exécuter git fetch, puis l'équivalent moral de git merge Origin/master. Donc, c'est presque identique à faire les deux étapes à la main, mais il y a quelques différences subtiles qui ne vous concernent probablement pas trop. (En particulier, l'étape fetch exécutée par pull apporte uniquementOrigin/master et ne met pas à jour la référence dans votre référentiel:1 toute nouvelle validation mentionnée uniquement par la référence spéciale FETCH_HEAD.)

Si vous utilisez la séquence git fetch Origin plus explicite (puis regardez autour de vous éventuellement) puis la séquence git merge Origin/master, vous pouvez également mettre à jour votre propre master locale avec la télécommande, 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.

1Cette deuxième partie a été modifiée - je dis "corrigée" - dans la version 1.8.4, qui met à jour les références de "branche distante" de manière opportuniste. (Comme le notent les notes de publication, il a été décidé délibérément de ne pas mettre à jour la mise à jour, mais il s'avère que de plus en plus de gens préfèrent que cette mise à jour soit effectuée par git. Ceci permet également une nouvelle fonctionnalité de git 1.9/2.0 pour la recherche de rebases en amont.)

518
torek

Situation : Je travaille dans ma branche locale, mais j'aime suivre régulièrement les mises à jour dans la branche de développement nommée dev.

Solution : Habituellement, je préfère faire:

git fetch
git rebase Origin/dev
6
greenridinghood

Scénario : 

J'ai la mise à jour principale et la mise à jour de ma branche. Je veux que ma branche garde la trace de son maître lors du changement de base, pour que tout l'historique soit correctement suivi, appelons ma branche Mybranch.

Solution : 

git checkout master    
git pull --rebase    
git checkout Mybranch    
git rebase master
git Push -f Origin Mybranch
  • besoin de résoudre tous les conflits avec git mergetool &, git rebase - continuer, git rebase - skip, git add -u, selon la situation et les astuces git, jusqu'à ce que tout soit résolu

(correction à la dernière étape, avec la permission de Tzachi Cohen, l'utilisation de "-f" force git à "mettre à jour l'historique" sur le serveur)

la branche doit maintenant être alignée sur le maître et rebasée, ainsi que sur la mise à jour à distance. Ainsi, dans git log, il n'y a ni "derrière" ni "devant", il suffit de supprimer tous les fichiers conflictuels locaux * .orig pour conserver le dossier "propre"

0
user10556443