Obtenir des modifications du maître en branche dans Git


690

Dans mon référentiel, j'ai une branche appelée sur aqlaquelle je travaille.

J'ai ensuite commis de nouveaux travaux et des bugs master.

Quelle est la meilleure façon d'obtenir ces commits dans la aqsuccursale? Créer une nouvelle branche masteret la fusionner avec aq?


3
À l'avenir, vous pouvez également démarrer votre branche de correction de bogues à partir d'un ancêtre commun du maître et d'autres branches qui auront besoin des correctifs, afin que vous puissiez les fusionner dans toutes ces branches, sans rien ramasser.
Cascabel

2
@Jefromi mais c'est hors de son contrôle s'il n'est pas le seul à travailler sur le projet. d'autres personnes mettent à jour le maître. diable, vous pouvez vous-même mettre à jour le maître à partir d'une troisième branche, et la situation serait inévitable et aurait besoin d'une solution générale.
ahnbizcad

@ahnbizcad Je suis quasiment sûr qu'il contrôle où il crée sa propre branche. Si sa branche est un ancêtre commun de ceux dans lesquels il voudra fusionner et que les gens s'ajoutent par la suite à ces branches, ce sera toujours un ancêtre commun.
Cascabel

les gars demandent, est-ce que cette commande le fait,git pull origin my_branch_name
Basheer AL-MOMANI

Réponses:


794

Consultez la aqbranche et rebasez à partir de master.

git checkout aq
git rebase master

le rebase peut-il provenir d'une autre branche? C'est à dire. git rebase otherbranch? Il semble que j'étais un peu déçu dans ma question, je me suis éloigné d'une branche, puis j'ai apporté des modifications à la branche d'origine.
Slee

2
Si je me trompe, rebasez sur la demande de tirage, il affichera toutes les validations principales. si vous utilisez merge / origin master, toutes les validations principales seront affichées comme 1 validation, ce qui facilite la révision du code.
Foo Bar User

4
Parfois, ce git mergeserait mieux. Si les deux branches ont évolué au fil du temps, vous devez déterminer celle qui vous convient le mieux.
erick2red

70
Tard dans la soirée, mais c'est un excellent aperçu du moment où rebaser vs fusionner: atlassian.com/git/tutorials/merging-vs-rebasing/…
ebuat3989

7
Si vos validations précédentes sur la branche aq sont publiques, ne faites pas de rebase. atlassian.com/git/tutorials/rewriting-history/git-rebase
Hanmant

301

Vous devriez pouvoir le faire git merge origin/masterlorsque vous êtes sur votre branche aq.

git checkout aq
git merge origin/master

55
Si le rebasage est «meilleur», cela dépend complètement de la situation spécifique.
Bombe

13
pourquoi ne pas simplement appeler "git merge master" au lieu de "git merge origin / master"?
Michael Küller

145
À utiliser rebasesi votre succursale est locale et n'a pas été poussée vers origin. À utiliser mergesi votre branche est déjà poussée. rebaseréécrira l'histoire.
garbagecollector

17
@Toskan, vous pouvez rencontrer des problèmes lorsque votre maître local n'est pas à jour avec la télécommande. De cette façon, il garantit que vous fusionnez dans la copie distante du code.
Chris Kooken

8
@garbagecollector Je suis contre le rebase (je peux, mais je ne rebaserai pas) Je ne vois aucune raison de jouer avec le rebase. Cela rend simplement les choses inutilement complexes. Vous avez toujours la question "Ai-je poussé cela vers la télécommande?" réfléchir et c'est une douleur à expliquer aux nouveaux arrivants. Certaines personnes disent que cela évite les validations de fusion. Mais je veux avoir des validations de fusion. Ils ne sont pas encombrants, ils documentent lorsque les branches sont fusionnées. Alors pour la dernière fois, pouvons-nous enfin arrêter d'agir comme nous nous engageons tous à maîtriser? Si vous n'aimez pas tellement les validations de fusion dans le journal, filtrez-les simplement avec --no-merges.
nurettin

92

Vérifiez d'abord pour maîtriser:

git checkout master

Effectuez toutes les modifications, correctifs et validations et poussez votre maître.

Retournez dans votre branche, 'aq', et fusionnez master en elle:

git checkout aq
git merge master

Votre agence sera à jour avec master. Un bon exemple basique de fusion est 3.2 Git Branching - Basic Branching and Merging .


25

Il n'y a aucune garantie que les corrections de bogues principaux ne figurent pas parmi les autres validations, vous ne pouvez donc pas simplement fusionner. Faire

git checkout aq
git cherry-pick commit1
git cherry-pick commit2
git cherry-pick commit3
...

en supposant que ces validations représentent les corrections de bogues.

À partir de maintenant cependant, conservez les corrections de bogues dans une branche distincte. Vous pourrez simplement

git merge hotfixes

quand vous voulez les rouler tous dans la branche de développement régulière.


17

Soit cherry-pickles validations pertinentes en branche aqou fusionnent branche masteren branche aq.


5
@Slee vous vous êtes répondu ... ce n'est pas la solution à cette situation
mtet88

13

Fusionnez-le avec aq

git checkout master
git pull
git checkout aq
git merge --no-ff master
git push

8

Moyen facile

# 1. Create a new remote branch A base on last master
# 2. Checkout A
# 3. Merge aq to A

7

Pour moi, j'avais déjà des changements en place et je voulais les dernières nouvelles de la branche de base. Je n'ai pas pu le faire rebaseet cherry-pickj'aurais pris une éternité, j'ai donc fait ce qui suit:

git fetch origin <base branch name>  
git merge FETCH_HEAD

donc dans ce cas:

git fetch origin master  
git merge FETCH_HEAD

7

Cela ( d'ici ) a fonctionné pour moi:

git checkout aq
git pull origin master
...
git push

Citant:

git pull origin masterrécupère et fusionne le contenu de la branche principale avec votre branche et crée un commit de fusion. En cas de conflit de fusion, vous en serez informé à ce stade et vous devrez résoudre les validations de fusion avant de poursuivre . Lorsque vous êtes prêt à envoyer vos validations locales, y compris votre nouvelle validation de fusion, au serveur distant, exécutez git push.


Il est important de noter que cette solution est parfaite si une fusion est requise spécifiquement, c'est-à-dire si la branche principale ne peut pas être rebasée pour une raison quelconque.
cudacoder

3

Vous avez plusieurs options. git rebase master aqsur la branche qui conservera les noms de commit, mais NE PAS REBASE s'il s'agit d'une branche distante. Vous pouvez le faire git merge master aqsi vous ne vous souciez pas de conserver les noms de commit. Si vous souhaitez conserver les noms de validation et qu'il s'agit d'une branche distante, la validation est effectuée git cherry-pick <commit hash>sur votre branche.


0

Vous pouvez également le faire en exécutant une seule ligne.
git merge aq master

Cela équivaut à

git checkout aq
git merge master

Cela ne fait pas ce que vous pensez qu'il fait. git merge a bfusionne les branches aet bdans la branche actuelle. Mais git merge alorsque vous êtes sur une branche, acela ne fait rien (c'est pourquoi cela ressemble un peu à ce qu'il fait ce que vous pensez qu'il fait). (Voir git-scm.com/docs/git-merge#Documentation/… .)
MikeBeaton

0

ÉDITER:

Ma réponse ci - dessous les documents un moyen de fusion masterdans aq, où si vous affichez les détails de la fusion , il répertorie les modifications apportées aqavant la fusion, pas les modifications apportées à master. J'ai réalisé que ce n'est probablement pas ce que vous voulez, même si vous pensez que c'est le cas!

Juste:

git checkout aq
git merge master

c'est bien.

Oui, cette simple fusion montrera que les modifications de masteront été apportées aqà ce point, et non l'inverse; mais ça va - puisque c'est ce qui s'est passé! Plus tard, lorsque vous fusionnerez enfin votre branche dans master, c'est quand une fusion affichera enfin toutes vos modifications telles qu'elles ont été apportées à master(ce qui est exactement ce que vous voulez, et c'est le commit où les gens s'attendent à trouver ces informations de toute façon).

J'ai vérifié et l'approche ci-dessous montre également exactement les mêmes changements (tous les changements effectués aqdepuis la séparation d' origine entre aqet master) que l'approche normale ci-dessus, lorsque vous fusionnez enfin tout master. Je pense donc que son seul véritable inconvénient (en plus d'être trop complexe et non standard ...: - /) est que si vous modifiez n modifications récentes avec git reset --hard HEAD~<n>et cela passe au-delà de la fusion, la version ci-dessous annule la «mauvaise» branche, que vous devez réparer à la main (par exemple avec git reflog& git reset --hard [sha]).


[Donc, ce que je pensais auparavant était que:]

Il y a un problème avec:

git checkout aq
git merge master

car les modifications affichées dans la validation de fusion (par exemple, si vous regardez maintenant ou plus tard dans Github, Bitbucket ou votre visualiseur d'historique git local préféré) sont les modifications apportées sur master, ce qui peut ne pas être ce que vous voulez.

D'autre part

git checkout master
git merge aq

affiche les modifications apportées à aq, ce qui est probablement ce que vous voulez. (Ou, du moins, c'est souvent ce que je veux!) Mais la fusion montrant les bons changements est sur la mauvaise branche!

Comment faire face?!

Le processus complet, se terminant par un commit de fusion montrant les modifications apportées sur aq (comme pour la deuxième fusion ci-dessus), mais avec la fusion affectant la branche aq, est:

git checkout master
git merge aq
git checkout aq
git merge master
git checkout master
git reset --hard HEAD~1
git checkout aq

Ceci: fusionne aq sur master, avance rapidement cette même fusion sur aq, l'annule sur master et vous remet sur aq!

J'ai l'impression de manquer quelque chose - cela semble être quelque chose que vous voudriez évidemment, et quelque chose qui est difficile à faire.

De plus, le rebase n'est PAS équivalent. Il perd les horodatages et l'identité des commits effectués sur aq, ce qui n'est pas non plus ce que je veux.


0

Scénario:

  • J'ai créé une branche à partir de master say branch-1 et l'ai envoyée à ma section locale.
  • Mon ami a créé une branche à partir de master say branch-2.
  • Il a commis quelques modifications de code à master.
  • Maintenant, je veux transférer ces modifications de la branche principale vers ma branche locale.

Solution

git stash // to save all existing changes in local branch
git checkout master // Switch to master branch from branch-1
git pull // take changes from the master
git checkout branch-1 // switchback to your own branch
git rebase master // merge all the changes and move you git head  forward
git stash apply // reapply all you saved changes 

Vous pouvez trouver des conflits sur votre fichier après avoir exécuté "git stash apply". Vous devez le réparer manuellement et maintenant vous êtes prêt à pousser.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.