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

Comment je m'y prendrais

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

Si j'ai une branche locale à partir d'une branche distante, je ne me sens pas à l'aise pour fusionner d'autres branches que celle-ci avec la branche distante. De plus, je ne pousserais pas mes changements tant que je ne serais pas satisfait de ce que je veux pousser et je ne pousserais pas du tout les choses qui ne concernent que moi et mon dépôt local. Dans votre description, il semble que test est seulement pour vous ? Donc aucune raison de le publier.

git essaie toujours de respecter vos changements et ceux des autres, et il en sera de même pour --rebase. Je ne pense pas pouvoir l'expliquer de manière appropriée, alors jetez un coup d'oeil à [the Git book - Rebasing][1] ou [git-ready : Intro into rebasing][2] pour une petite description. C'est une fonctionnalité assez cool

[1] : http://git-scm.com/book/en/Git-Branching-Rebasing [2] : http://gitready.com/intermediate/2009/01/31/intro-to-rebase.html

Il s'agit d'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 présente deux problèmes :

1. Elle n'est pas sûre, car nous ne savons pas s'il y a des conflits entre la branche test et la branche master.

2. Cela "comprimerait" tous les commits de test en un seul commit de fusion sur master ; c'est-à-dire que sur la branche master, nous ne pouvons pas voir tous les journaux de changement de la branche test.

Ainsi, lorsque nous soupçonnons qu'il y a des conflits, nous pouvons effectuer les 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, éviter un fast-forward commit par --no-ff,

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

git status

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

git commit -m 'merge test branch'
git push

Mais de cette façon, nous perdons l'historique des modifications enregistrées dans la branche de test, et il serait difficile pour les autres développeurs de comprendre l'historique du projet dans la branche principale.

La meilleure méthode est donc d'utiliser rebase au lieu de merge (en supposant qu'à ce moment-là, nous ayons résolu les conflits de branches).

Voici un exemple simple, pour les opérations avancées, veuillez vous référer à http://git-scm.com/book/en/v2/Git-Branching-Rebasing.

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

Oui, lorsque vous avez effectué les remontages, tous les commits de la branche Test seront déplacés vers la tête de la branche Master. Le principal avantage du rebasage est que vous obtenez un historique linéaire et beaucoup plus propre du projet.

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

Ne faites jamais d'opérations comme les suivantes :

git checkout master
git rebase -i test

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

annexe :

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

L'approche habituelle lors du 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

Quand vous êtes prêt à fusionner à nouveau dans master,

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

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

Utiliser le push puis le pull comme moyen de fusion est stupide. Je ne suis pas non plus sûr de la raison pour laquelle vous poussez test vers origin.