Question Meilleur (et le plus sûr) moyen de fusionner une branche git en master


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

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

Disons que le travail sur test prend plusieurs jours et que vous voulez garder continuellement test mis à jour avec commits à l'intérieur 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 j'ai travaillés.


Mon travail sur test est fait et je suis prêt à le fusionner à master. Voici les deux façons dont je peux penser:

UNE: 

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 ma compréhension, rebase obtiendra les changements de master et empiler le mien sur le dessus de cela d'où il pourrait écraser les changements d'autres personnes faites.

Question 2: Laquelle de ces deux méthodes est correcte? Quelle est la différence là-bas?

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


1463
2018-04-09 00:01


origine


Réponses:


Comment je ferais ça

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

Si j'ai une branche locale d'une branche distante, je ne me sens pas à l'aise de fusionner d'autres branches que celle-ci avec la télécommande. Aussi je ne pousserais pas mes changements, jusqu'à ce que je sois heureux avec ce que je veux pousser et aussi je ne pousserais pas les choses du tout, qui sont seulement pour moi et mon référentiel local. Dans votre description, il semble que test est seulement pour vous? Donc pas de raison de le publier.

git essaie toujours de respecter les vôtres et les autres changements, et ainsi --rebase. Je ne pense pas pouvoir l'expliquer correctement, alors jetez un oeil à le livre Git - Rebasing ou git-ready: Intro dans rebasing pour une petite description. C'est une fonctionnalité plutôt cool


2158
2018-04-09 00:45



C'est une question très pratique, mais toutes les réponses ci-dessus ne sont pas pratiques.

Comme

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

Cette approche a deux problèmes:

  1. C'est dangereux, car nous ne savons pas s'il y a des conflits entre la branche de test et la branche principale.

  2. Cela "écraserait" toutes les validations de test dans un commit de fusion sur master; c'est-à-dire sur la branche master, nous ne pouvons pas voir tous les logs de changement de branche de test.

Donc, quand nous suspectons qu'il y aura des conflits, nous pouvons avoir des opérations git suivantes:

git checkout test
git pull 
git checkout master
git pull
git merge --no-ff --no-commit test

Tester merge avant commit, évitez une validation rapide par --no-ff,

Si un conflit est rencontré, nous pouvons courir git status pour vérifier les détails sur les conflits et essayer de résoudre

git status

Une fois que nous résolvons les conflits, ou s'il n'y a pas de conflit, nous commit et push leur

git commit -m 'merge test branch'
git push

Mais cette façon de procéder perdra l'historique des changements consignés dans la branche de test, et cela rendrait la branche master difficile à comprendre pour les autres développeurs en ce qui concerne l'historique du projet.

Donc, la meilleure méthode est que nous devons utiliser rebase au lieu de merge (Supposons que nous ayons résolu les conflits de branche à ce moment-là).

Voici un exemple simple, pour les opérations avancées, s'il vous plaît se référer à http://git-scm.com/book/fr/v2/Git-Branching-Rebasing

git checkout master
git pull
git checkout test
git pull
git rebase -i master
git checkout master
git merge test

Eh oui, quand vous avez fini, tous les commits de la branche Test seront déplacés sur la tête de la branche Maître. Le principal avantage du rebasage est que vous obtenez un historique de projet linéaire et beaucoup plus propre.

La seule chose que vous devez éviter est: ne jamais utiliser rebase sur la branche publique, comme la branche principale.

comme opération suivante:

git checkout master
git rebase -i test

Ne faites jamais ces opérations.

Détails pour https://www.atlassian.com/git/tutorials/merging-vs-rebasing/the-golden-rule-of-rebasing

annexe:


260
2018-03-14 12:13



Ni un rebasage ni une fusion ne doivent écraser les changements de quiconque (sauf si vous choisissez de le faire lors de la résolution d'un conflit).

L'approche habituelle en cours de développement est

git checkout master
git pull
git checkout test
git log master.. # if you're curious
git merge origin/test # to update your local test from the fetch in the pull earlier

Lorsque vous êtes prêt à fusionner avec le maître,

git checkout master
git log ..test # if you're curious
git merge test
git push

Si vous craignez de casser quelque chose lors de la fusion, git merge --abort est là pour toi.

Utiliser la poussée puis tirer comme un moyen de fusionner est stupide. Je ne suis pas sûr de savoir pourquoi vous faites passer le test à l'origine.


73
2018-04-10 00:17



outre KingCrunches réponse, Je suggère d'utiliser

git checkout master
git pull origin master
git merge --squash test
git commit
git push origin master

Vous avez peut-être effectué plusieurs validations dans l'autre branche, ce qui ne devrait être qu'un commit dans la branche master. Pour que l'historique des commit soit aussi propre que possible, vous pourriez vouloir écraser tous vos commits de la branche test en un commit dans la branche master (voir aussi: Git: Pour écraser ou ne pas écraser?). Ensuite, vous pouvez également réécrire le message de commit à quelque chose de très expressif. Quelque chose qui est facile à lire et à comprendre, sans creuser dans le code.

edit: Vous pourriez être intéressé par

Donc, sur GitHub, je finis par faire ce qui suit pour une branche de fonctionnalité mybranch:

Obtenez les dernières d'origine

$ git checkout master
$ git pull origin master

Trouver le hachage de base de fusion:

$ git merge-base mybranch master
c193ea5e11f5699ae1f58b5b7029d1097395196f

$ git checkout mybranch
$ git rebase -i c193ea5e11f5699ae1f58b5b7029d1097395196f

Maintenant, assurez-vous que le premier est pick, le reste est s:

pick 00f1e76 Add first draft of the Pflichtenheft
s d1c84b6 Update to two class problem
s 7486cd8 Explain steps better

Ensuite, choisissez un très bon message de commit et poussez sur GitHub. Faites la demande de traction alors.

Après la fusion de la requête pull, vous pouvez le supprimer localement:

$ git branch -d mybranch

et sur GitHub

$ git push origin :mybranch

20
2018-04-21 08:18



C'est le flux de travail que j'utilise dans mon travail avec l'équipe. Le scénario est tel que vous l'avez décrit. D'abord, quand j'ai fini de travailler test Je rebase avec le maître pour tirer tout ce qui a été ajouté au master pendant le temps que j'ai travaillé sur le test branche.

git pull -r upstream master

Cela va tirer les changements à maîtriser depuis que vous avez fourchu le test branchez-les et appliquez-les, puis appliquez les modifications que vous avez apportées pour tester «par-dessus» l'état actuel du maître. Il peut y avoir des conflits ici, si les autres personnes ont apporté des modifications aux mêmes fichiers que vous avez édités en test. S'il y en a, vous devrez les corriger manuellement et les valider. Une fois que vous avez fait cela, vous pouvez passer à la branche principale et fusionner testdans sans problèmes.


3
2018-03-16 22:27



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 lorsque vous fusionnez, l'erreur "Resolve Conflict"

Alors vous devez d'abord résoudre tous vos conflits, puis vous devez recommencer tous vos changements et ensuite pousser

git push origin master

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


1
2018-04-07 08:55