Question Mettre à jour les branches Git du maître


Je suis nouveau pour Git, et maintenant je suis dans cette situation:

  • J'ai quatre branches (maître, b1, b2 et b3).
  • Après avoir travaillé sur b1-b3, je me suis rendu compte que je devais changer quelque chose sur le maître de la branche qui devrait se trouver dans toutes les autres branches.
  • J'ai changé ce dont j'avais besoin master et ... voici mon problème:

Comment mettre à jour toutes les autres branches avec master code de branche?


466
2017-10-06 21:18


origine


Réponses:


Vous avez deux options:

Le premier est une fusion, mais cela crée un commit supplémentaire pour la fusion.

Checkout chaque branche:

git checkout b1

Puis fusionnez:

git merge origin/master

Poussez ensuite:

git push origin b1

Alternativement, vous pouvez faire un rebase:

git fetch
git rebase origin/master

388
2017-10-06 21:21



Vous avez essentiellement deux options:

  1. Vous fusionnez. C'est en fait assez simple, et une opération parfaitement locale:

    git checkout b1
    git merge master
    # repeat for b2 and b3
    

    Cela laisse l'histoire exactement comme elle s'est passée: Vous avez bifurqué à partir du maître, vous avez fait des changements à toutes les branches, et finalement vous avez incorporé les changements de maître dans les trois branches.

    git peut gérer cette situation vraiment bien, il est conçu pour que les fusions se produisent dans toutes les directions, en même temps. Vous pouvez être sûr qu'il sera capable de rassembler tous les threads correctement. Il ne se soucie pas simplement de savoir si la branche b1 fusionne master, ou master fusionne b1, le commit de fusion ressemble tout de même à git. La seule différence est la branche qui pointe vers ce commit de fusion.

  2. Vous rebassez. Les personnes avec un SVN ou un arrière-plan similaire trouvent cela plus intuitif. Les commandes sont analogues à la casse de fusion:

    git checkout b1
    git rebase master
    # repeat for b2 and b3
    

    Les gens aiment cette approche car elle conserve une histoire linéaire dans toutes les branches. Cependant, cette histoire linéaire est un mensonge, et vous devriez être conscient que c'est le cas. Considérez ce graphique de validation:

    A --- B --- C --- D <-- master
     \
      \-- E --- F --- G <-- b1
    

    La fusion aboutit à l'histoire vraie:

    A --- B --- C --- D <-- master
     \                 \
      \-- E --- F --- G +-- H <-- b1
    

    La rebase, cependant, vous donne cette histoire:

    A --- B --- C --- D <-- master
                       \
                        \-- E' --- F' --- G' <-- b1
    

    Le fait est que les commits E', F', et G' n'a jamais vraiment existé et n'a probablement jamais été testé. Ils peuvent même pas compiler. Il est en fait assez facile de créer des commits absurdes via un rebase, en particulier lorsque les changements de master sont importants pour le développement de b1.

    La conséquence de ceci peut être, que vous ne pouvez pas distinguer lequel des trois commits E, F, et G effectivement introduit une régression, ce qui diminue la valeur de git bisect.

    Je ne dis pas que vous ne devriez pas utiliser git rebase. Il a ses utilisations. Mais chaque fois que vous l'utilisez, vous devez être conscient du fait que vous mentez sur l'histoire. Et vous devriez au moins compiler le test des nouveaux commits.


364
2018-02-13 17:44



git rebase master est la bonne façon de le faire. La fusion signifierait qu'un commit serait créé pour la fusion, alors que le rebasage ne le serait pas.


221
2018-04-20 06:03



Si vous avez travaillé sur une branche de façon intermittente, ou si beaucoup de choses se sont passées dans d'autres branches pendant que vous travaillez sur quelque chose, il est préférable de rebaser votre branche sur master. Cela permet de garder l’histoire bien rangée et rend les choses beaucoup plus faciles à suivre.

git checkout master
git pull
git checkout local_branch_name
git rebase master
git push --force # force required if you've already pushed

Remarques:

  • Ne rebase pas les branches avec lesquelles vous avez collaboré avec d’autres.
  • Vous devriez rebaser sur la branche à laquelle vous allez fusionner et qui ne sera pas toujours maîtrisée.

Il y a un chapitre sur le rebasage à http://git-scm.com/book/ch3-6.html, et d’autres ressources sur le Web.


41
2017-10-11 11:14



Vous pouvez fusionner, ou vous pouvez appliquer des validations individuelles à travers les branches en utilisant Git cerise.


8
2017-10-06 21:27



@cmaster a fait la meilleure réponse élaborée. En bref:

git checkout master #
git pull # update local master from remote master
git checkout <your_branch>
git merge master # solve merge conflicts if you have`

Vous ne devez pas réécrire l’historique des succursales mais les conserver pour des références futures. Lors de la fusion en master, cela crée un commit supplémentaire mais c'est bon marché. Commits ne coûte pas


8
2018-01-18 10:08



Pour mettre à jour d'autres branches comme (sauvegarde) avec votre copie de branche principale. Vous pouvez faire comme suit (rebaser ou fusionner) ...

  1. Refaire (il n'y aura aucun commit supplémentaire à la branche de sauvegarde).
  2. Fusionner les branches (il y aura automatiquement un commit supplémentaire pour le branche de sauvegarde).

    Remarque: La base de données n'est rien d'autre qu'une nouvelle base (une nouvelle copie)

git checkout backup
git merge master
git push

(Répétez pour les autres branches s'il y en a comme backup2 & etc.)

git checkout backup
git rebase master
git push

(Répétez pour les autres branches s'il y en a comme backup2 & etc.)


4
2018-01-17 13:54