2385 votes

Quelle est la meilleure (et la plus sûre) façon de fusionner une branche Git dans master ?

Une nouvelle branche de master est créé, nous l'appelons test .

Il y a plusieurs développeurs qui s'engagent soit à master ou créer d'autres branches et les fusionner plus tard dans master .

Disons que le travail sur test prend plusieurs jours et vous voulez continuer à garder test mis à jour avec des commits dans master .

Je ferais git pull origin master de test .

Question 1 : Est-ce la bonne approche ? D'autres développeurs auraient pu facilement travailler sur les mêmes fichiers que moi.


Mon travail sur test est terminé et je suis prêt à le fusionner de nouveau avec master . Voici les deux moyens auxquels je pense :

A :

git checkout test
git pull origin master
git push origin test
git checkout master
git pull origin test 

B :

git checkout test
git pull origin master
git checkout master
git merge test

Je n'utilise pas --rebase parce que d'après ce que j'ai compris, rebase récupérera les modifications de master et empiler le mien par-dessus, ce qui pourrait écraser les changements faits par d'autres personnes.

Question 2 : Laquelle de ces deux méthodes est la bonne ? Quelle est la différence ?

Le but dans tout ça est de garder mon test mis à jour avec les choses qui se passent dans master et plus tard, je pourrais les fusionner à nouveau dans master en espérant garder la chronologie aussi linéaire que possible.

27 votes

Non rebase n'écrase jamais, il essaie juste d'obtenir un historique plus propre. en rattachant (ou en falsifiant) l'historique au dernier point du maître

9 votes

Rebase n'écrase pas vos commits. Il annule vos commits, applique les commits de la branche master à votre branche test, puis applique vos commits à nouveau à test.

1 votes

Que faire si nous n'avons pas d'accès en écriture à master ? Y a-t-il un moyen de résoudre les conflits de manière préemptive sur la branche des fonctionnalités ? Probablement pas, je suppose, puisque les histoires ont probablement divergé.

7voto

djheru Points 505

C'est le flux de travail que j'utilise dans mon travail avec l'équipe. Le scénario est celui que vous avez décrit. D'abord, quand j'ai fini de travailler sur test Je rebase avec master pour intégrer tout ce qui a été ajouté à master pendant la période où j'ai travaillé sur le projet. test branche.

git pull -r upstream master

Cela va tirer les changements vers master puisque vous avez bifurqué vers le fichier test et les appliquer, et ensuite appliquer les changements que vous avez fait pour tester "par dessus" l'état actuel de master. Il peut y avoir des conflits ici, si d'autres personnes ont apporté des modifications aux mêmes fichiers que ceux que vous avez modifiés dans test. Si c'est le cas, vous devrez les corriger manuellement et faire un commit. Une fois cela fait, vous pourrez passer à la branche master et fusionner test sans aucun problème.

5voto

Vinay Sikarwar Points 411
git checkout master
git pull origin master
# Merge branch test into master
git merge test

Après la fusion, si le fichier est modifié, alors quand vous fusionnez, il y aura une erreur de "Résoudre le conflit".

Il faut donc d'abord résoudre tous les conflits, puis valider toutes les modifications et enfin pousser le système.

git push origin master

C'est mieux de faire qui a fait des changements dans la branche de test, parce qu'il sait quels changements il a fait.

5voto

Artur Points 478

J'utiliserais la méthode rebase. Principalement parce qu'elle reflète parfaitement votre cas sémantiquement, c'est-à-dire que ce que vous voulez faire est de rafraîchir l'état de votre branche actuelle et de "faire semblant" comme si elle était basée sur la dernière.

Donc, sans même vérifier master je le ferais :

git fetch origin
git rebase -i origin/master
# ...solve possible conflicts here

Bien sûr, le simple fait de récupérer des données depuis l'origine ne rafraîchit pas l'état local de l'utilisateur. master (puisqu'il n'effectue pas de fusion), mais c'est tout à fait acceptable pour notre objectif - nous voulons éviter de faire des allers-retours, pour gagner du temps.

4voto

cgnorthcutt Points 699

La réponse de @KingCrunch devrait fonctionner dans de nombreux cas. Un problème qui peut se poser est que vous pouvez être sur une autre machine qui a besoin de tirer la dernière version de test. Je recommande donc d'extraire d'abord test. La révision ressemble à ceci :

git checkout test
git pull
git checkout master
git pull origin master
git merge test
git push origin master

4voto

omkar Points 186

Je répondrai en fonction des branches de développement et de fonctionnalité,

si vous êtes sur la branche feature et que vous avez besoin de la mettre à jour avec develop, utilisez les commandes ci-dessous :

git checkout develop
git pull
git checkout feature/xyz
git merge develop

Maintenant, votre feature/xyz est mis à jour avec develop et vous pouvez pousser vos changements à distance feature/xyz .

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X