git pull du maître dans la direction du développement

Question

J’ai une branche appelée dmgr2 (développement) et je tiens à tirer de la branche master (site en ligne) et d’intégrer tous les changements dans ma branche de développement. y a-t-il une meilleure façon de le faire ? Voici ce que j’avais prévu de faire :

Cela devrait tirer le direct se transforme en ma branche de développement, ou me faire ce tort ?

Answer 1

Les étapes que vous avez énumérés au travail, mais il y a un plus long chemin 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

L' fetch commande peut être fait à n'importe quel moment avant l' merge, c'est à dire, vous pouvez inverser l'ordre de l'extraction et de la caisse, parce qu' fetch va juste à l'nommé à distance (origin) et dit: "donne-moi tout ce que vous avez que je n'ai pas", c'est à dire, tous les commits sur toutes les branches. Elles sont copiées dans le référentiel, mais nommé origin/branch pour toute branche nommée branch sur la télécommande.

À ce stade, vous pouvez utiliser n'importe quel observateur (git log, gitk, etc) pour voir "ce qu'ils ont" que vous ne le faites pas, et vice versa. Parfois, ce n'est utile que pour des affinités Sentiments ("ah, oui, c'est en fait ce que je veux") et parfois, il est utile pour modifier des stratégies entièrement ("whoa, je ne veux pas QUE des trucs encore").

Enfin, l' merge commande prend la validation donnée, que vous pouvez nommer comme origin/master, et fait tout ce qu'il faut pour ramener en qui s'engagent et de ses ancêtres, quelle que soit la branche que vous sur lorsque vous exécutez l' merge. Vous pouvez insérer --no-ff ou --ff-only pour prévenir une avance rapide ou de fusion et seulement si le résultat est un fast-forward, si vous le souhaitez.

Lorsque vous utilisez la séquence:

git checkout dmgr2
git pull origin master

l' pull commande indique à git pour exécuter git fetch, puis l'équivalent moral de l' git merge origin/master. Donc, c'est presque le même que le fait de faire les deux étapes de la main, mais il ya quelques différences subtiles qui ne sont probablement pas trop en ce qui concerne vous. (En particulier l' fetch étape exécuter en pull apporte plus seulement origin/master, et il ne met pas à jour la ref dans votre repo:¹ tout nouveau commet des vents jusqu'à se référer à une seule par l' FETCH_HEAD référence.)

Si vous utilisez le plus explicite git fetch origin (puis éventuellement regarder autour), puis git merge origin/master de la séquence, vous pouvez également apporter votre propre local master jusqu'à la date de la télécommande, avec un seul fetch courir à travers 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.

---

¹Cette deuxième partie a été changé-je dire "fixe"-dans git 1.8.4, qui met à jour maintenant "à distance" des références de façon opportuniste. (Il a été, comme les notes de dire, délibérée d'une décision de conception d'ignorer la mise à jour, mais il s'avère que de plus en plus de gens préfèrent que git le mettre à jour. Si vous voulez que le vieux à distance-direction générale de l'algorithme SHA-1, la valeur par défaut est d'être sauvé, et donc récupérables à partir, le reflog. Cela permet également d'effectuer un nouveau dépôt git 1.9/2.0 pour la recherche en amont rebases.)

Answer 2

Basé sur la question, je pense que cela devrait être un rebasage pas fusionner. La fusion peut survenir après que les changements sont réconciliés.