Une nouvelle branche de master
est créée, nous l'appelons test
.
Il y a plusieurs développeurs qui soit commettent dans master
, soit créent d'autres branches et fusionnent plus tard dans master
.
Disons que le travail sur test
prend plusieurs jours et que vous voulez garder test
continuellement à jour avec les commits dans master
.
Je ferais git pull origin master
depuis 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 à nouveau avec master
. Voici les deux façons auxquelles 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ère les modifications de master
et empile les miennes par-dessus, ce qui pourrait écraser les modifications apportées par d'autres personnes.
Question 2: Laquelle de ces deux méthodes est la bonne ? Quelle est la différence ?
Le but de tout cela est de garder ma branche test
à jour avec les choses qui se passent dans master
et plus tard je pourrais les fusionner à nouveau dans master
en espérant garder la ligne de temps aussi linéaire que possible.
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 :
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.
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.