J'ai mon master et une develop pour travailler sur quelques changements. Je dois fusionner les changements de master en develop mais finira par fusionner tout ce qui provient de develop en master . J'ai deux flux de travail différents en tête :
git pull origin master en develop branchegit merge master en develop brancheQuelle est la meilleure façon de procéder, et pourquoi ?
Ce flux de travail fonctionne le mieux pour moi :
git checkout -b develop...faire quelques changements...
...remarquez que le maître a été mis à jour...
...engager des changements pour développer...
git checkout master
git pull...ramener ces changements dans le développement...
git checkout develop
git rebase master...faire d'autres changements...
...les engager à développer...
...les fusionner dans master...
git checkout master
git pull
git merge develop
C'est aussi ma façon de travailler, et je trouve que cela fonctionne bien. Il y a une chose que je ne fais pas, cependant, et c'est le git pull juste avant la finale git merge develop . Quel est le but de tout cela ?
Après la partie ...notice master has been updated..., le checkout master ne va-t-il pas effacer vos modifications locales pour les développer si vous ne les livrez pas ?
@a1an Non, mais si vous ne les livrez pas, les changements seront transférés sur la branche master et git ne vous laissera pas tirer tant qu'ils n'auront pas été livrés.
Pourtant, est-il sûr de rebaser et d'a git push origin rebasedBranch --force sur un repo privé ? Le seul utilisateur est moi-même.
Oui, si vous êtes le seul utilisateur, bien sûr que c'est sûr. J'utilise git push --force tout le temps quand je suis le seul utilisateur. :)
Je fais écho à l'avertissement d'Eric. Cependant, il est tout à fait possible de rebaser votre propre branche distante. Jouez avec rebase et merge et vous comprendrez les avantages et les inconvénients de chacun et saurez quand les utiliser.
La meilleure approche pour ce genre de chose est probablement git rebase . Cela vous permet de tirer des changements 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 commit) du travail de master. Lorsque votre nouveau travail est terminé, la fusion vers master est alors très simple.
@KarlBielefeldt Si develop est partagé avec d'autres contributeurs, comment mettrions-nous à jour develop quand certains correctifs ont été poussés directement vers master ? Devrions-nous 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.
Si vous ne partagez pas la branche de développement avec qui que ce soit, je me contenterais de la rebaser à chaque mise à jour de master, de cette façon vous n'aurez pas de commits de fusion partout dans votre historique une fois que vous aurez fusionné la branche de développement dans master. Le flux de travail 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 developLes étapes ci-dessus garantissent que votre branche de développement sera toujours au courant des dernières modifications de la branche master. Une fois que vous avez terminé avec la branche de développement et qu'elle a été rebasée sur les dernières modifications de master, vous pouvez simplement la fusionner à nouveau :
> git checkout -b master
> git merge develop
> git branch -d develop
Ma règle d'or est la suivante :
rebasepour les branches avec le même nom ,mergeautrement.
Les exemples pour les mêmes noms seraient master , origin/master y otherRemote/master .
si develop n'existe que dans le référentiel local, et il est toujours basé sur une récente origin/master vous devriez l'appeler master Cela vous simplifie la vie et vous présente les choses telles qu'elles sont réellement : vous développez directement sur le site de l'entreprise. master branche.
si develop est partagée, elle ne doit pas être rebasée sur master qui vient d'être fusionné avec --no-ff . vous développez sur develop . master y develop ont des noms différents, parce que nous voulons qu'ils soient des choses différentes, et qu'ils restent séparés. ne les rendez pas identiques avec rebase .
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.
18 votes
Lecture recommandée : nvie.com/posts/a-successful-git-branching-model
2 votes
git pull=git fetch+git merge FETCH_HEAD