«Git pull» ou «git merge» entre les branches master et développement

243

J'ai ma masterbranche et une developbranche pour travailler sur quelques changements. J'ai besoin de fusionner les changements de masteren develop, mais je fusionnerai finalement tout de developen master. J'ai deux workflows différents en tête:

git pull origin masteren developbranche
git merge masteren developbranche

Quelle est la meilleure façon de procéder et pourquoi?

git workflow

— Carson
source

18

Lecture recommandée: nvie.com/posts/a-successful-git-branching-model

— Alex Brasetvik

2

git pull= git fetch+git merge FETCH_HEAD

— Yousha Aleayoub

104

Soyez prudent avec rebase. Si vous partagez votre branche de développement avec qui que ce soit, le rebase peut gâcher les choses. Rebase n'est valable que pour vos propres succursales locales.

En règle générale, si vous avez poussé la branche à l'origine, n'utilisez pas de rebase. Utilisez plutôt la fusion.

— Eric mène
source

Pourtant, est-il sûr de rebaser et git push origin rebasedBranch --forcesur un repo privé? Le seul utilisateur est moi-même.

— k0pernikus

Oui, si vous êtes le seul utilisateur, bien sûr, c'est sûr. J'utilise git push --force tout le temps quand je suis le seul utilisateur. :)

— Tyler Rick

3

Je fais écho à l'avertissement d'Eric. Cependant, il est parfaitement normal de rebaser également votre propre branche distante. Jouez avec rebase et fusion et vous comprendrez les avantages et les inconvénients de chacun et apprendrez quand les utiliser.

— Ian Lotinsky

Bon article sur l'utilisation de rebase, même la fusion après la résolution de conflits: github.com/everpix/Everpix-Intelligence

— Ian Lotinsky

@IanLotinsky votre lien ne pointe pas vers un article sur le rebase. Longshot, mais avez-vous toujours le bon lien? :)

— Daniel Serodio

347

Ce flux de travail fonctionne le mieux pour moi:

git checkout -b develop

... apportez quelques modifications ...

... avis maître a été mis à jour ...

... engager des changements à développer ...

git checkout master
git pull

... ramener ces changements dans le développement ...

git checkout develop
git rebase master

... apportons quelques modifications supplémentaires ...

... les engager à se développer ...

... les fusionner en maître ...

git checkout master
git pull
git merge develop

— Ian Lotinsky
source

2

C'est comme ça que je travaille aussi, et je trouve que ça marche bien. Il y a une chose que je ne fais pas cependant, et c'est git pulljuste avant la finale git merge develop. Quel est le but de cela?

— crdx

Après que la ... notice master a été mise à jour ... partie, le checkout master n'effacera-t-il pas vos modifications locales à développer si vous ne les validez pas?

— a1an

1

@ a1an Non, mais si vous ne les validez pas, les modifications seront déplacées vers la branche principale et git ne vous laissera pas tirer jusqu'à ce qu'elles soient validées.

— elemjay19

5

@crdx Il est probable que d'autres branches soient fusionnées avec le maître distant avant de fusionner votre branche avec votre maître local. Vous extrayez et apportez les modifications du maître distant à votre copie locale du maître. Voilà comment je l'ai compris.

— Tarun

12

git pull --rebase origin mastersur votre branche de développement est un peu plus rapide.

— Nathan Lilienthal

24

La meilleure approche pour ce genre de chose est probablement git rebase. Il vous permet d'extraire les modifications de master dans votre branche de développement, mais de laisser tout votre travail de développement "au-dessus" (plus tard dans le journal de validation) du stuff de master. Lorsque votre nouveau travail est terminé, la fusion avec Master est alors très simple.

— divegeek
source

10

Bon conseil, en supposant qu'il developn'est partagé avec personne d'autre.

— Karl Bielefeldt

1

@KarlBielefeldt Si develop est partagé avec d'autres contributeurs, comment pourrions-nous mettre developà jour lorsque certains correctifs ont été poussés directement vers master? Faut-il faire une fusion, c'est à dire git checkout master && git pull --rebase && git checkout develop && git merge master? J'ai laissé un commentaire sur la réponse la plus votée ci-dessus, qui détaille également cette préoccupation.

— modulitos

5

Si vous ne partagez pas la branche de développement avec quelqu'un, alors je la rebaserais à chaque fois que master est mis à jour, de cette façon vous n'aurez pas de commit de fusion partout dans votre historique une fois que vous fusionnerez develop de nouveau en master. Le workflow dans ce cas serait le suivant:

> git clone git://<remote_repo_path>/ <local_repo>
> cd <local_repo>
> git checkout -b develop
....do a lot of work on develop
....do all the commits
> git pull origin master
> git rebase master develop

Les étapes ci-dessus garantiront que votre branche de développement sera toujours au courant des dernières modifications de la branche principale. Une fois que vous avez terminé avec la branche de développement et qu'elle est rebasée aux dernières modifications sur le maître, vous pouvez simplement la fusionner à nouveau:

> git checkout -b master
> git merge develop
> git branch -d develop

— KiRPiCH
source

1

ma règle d'or est la suivante:

rebasepour les succursales du même nom , mergesinon.

des exemples pour les mêmes noms seraient master, origin/masteret otherRemote/master.

s'il developn'existe que dans le référentiel local et qu'il est toujours basé sur une origin/mastervalidation récente , vous devez l'appeler masteret y travailler directement. il vous simplifie la vie et présente les choses telles qu'elles sont: vous vous développez directement sur la masterbranche.

s'il developest partagé, il ne doit pas être rebasé master, simplement fusionné avec --no-ff. vous développez sur develop. masteret developont des noms différents, parce que nous voulons qu'ils soient des choses différentes, et restent séparés. ne les faites pas de même avec rebase.

— hoijui
source