Question Quand devrais-je utiliser git pull --rebase?


Je connais des gens qui utilisent git pull --rebase par défaut et d'autres qui insistent pour ne jamais l'utiliser. Je crois comprendre la différence entre la fusion et le rebasing, mais j'essaie de mettre cela dans le contexte de git pull. Est-ce juste de ne pas vouloir voir beaucoup de messages de validation de fusion, ou y a-t-il d'autres problèmes?


633
2018-03-18 18:04


origine


Réponses:


Tu devrais utiliser git pull --rebase quand

  • vos changements ne méritent pas une branche distincte

En effet - pourquoi pas alors? C'est plus clair, et n'impose pas groupement logique sur vos commits.


Ok, je suppose qu'il a besoin de clarification. Dans Git, comme vous le savez probablement, vous êtes encouragé à fusionner et à fusionner. Votre branche locale, dans laquelle vous tirez des modifications, et la branche distante sont, en fait, différentes branches, et git pull est de les fusionner. C'est raisonnable, puisque vous ne poussez pas très souvent et accumulez généralement un certain nombre de changements avant qu'ils ne constituent une fonctionnalité terminée.

Cependant, parfois - pour une raison quelconque - vous pensez que ce serait mieux si ces deux - lointains et locaux - étaient un branche. Comme dans SVN. C'est ici git pull --rebase entre en jeu. Vous ne fusionnez plus - vous en fait valider au-dessus de la branche distante. C'est ce dont il s'agit réellement.

Que ce soit dangereux ou non, c'est la question de savoir si vous traitez une branche locale ou éloignée comme une chose inséparable. Parfois c'est raisonnable (quand vos changements sont petits, ou si vous êtes au début d'un développement robuste, quand des changements importants sont apportés par de petits commits). Parfois, ce n'est pas le cas (quand vous créez normalement une autre branche, mais vous étiez trop paresseux pour le faire). Mais c'est une question différente.


448
2018-03-18 19:01



Je voudrais donner un point de vue différent sur ce que signifie réellement «git pull --rebase», car il semble parfois se perdre.

Si vous avez déjà utilisé Subversion (ou CVS), vous pouvez être habitué au comportement de "svn update". Si vous avez des modifications à valider et que la validation échoue parce que des modifications ont été effectuées en amont, vous "svn update". Subversion procède en fusionnant les modifications en amont avec les vôtres, ce qui peut entraîner des conflits.

Ce que Subversion vient de faire, c'était essentiellement "pull --rebase". Le fait de reformuler vos modifications locales pour qu'elles soient relatives à la nouvelle version est la partie "rebasing" de celle-ci. Si vous avez effectué "svn diff" avant la tentative de validation échouée, et comparez ensuite le diff résultant avec la sortie de "svn diff", la différence entre les deux diff est ce que l'opération de rebasement a fait.

La différence majeure entre Git et Subversion dans ce cas est que dans Subversion, "vos" changements ne sont que des changements non-validés dans votre copie de travail, alors que dans Git vous avez des commits réels localement. En d'autres termes, dans Git vous avez fourchu l'histoire; votre histoire et l'histoire en amont ont divergé, mais vous avez un ancêtre commun.

À mon avis, dans le cas normal où votre succursale locale reflète simplement la branche en amont et y fait continuellement du développement, la bonne chose à faire est toujours «--rebase», parce que c'est ce que vous êtes sémantiquement Faire. Vous et d'autres êtes en train de pirater l'histoire linéaire prévue d'une branche. Le fait que quelqu'un d'autre ait poussé légèrement avant votre tentative de poussée n'est pas pertinent, et il semble contre-productif que chaque accident de ce genre entraîne des fusions dans l'histoire.

Si vous ressentez le besoin de quelque chose d'être une branche pour une raison quelconque, c'est une préoccupation différente à mon avis. Mais à moins que vous ayez un désir spécifique et actif de représenter vos changements sous la forme d'une fusion, le comportement par défaut devrait, à mon avis, être "git pull --rebase".

Veuillez considérer d'autres personnes qui ont besoin d'observer et de comprendre l'histoire de votre projet. Voulez-vous l'histoire jonchée de centaines de fusions partout, ou voulez-vous seulement les quelques fusions sélectionnées qui représentent des fusions réelles d'efforts de développement intentionnels divergents?


608
2018-01-13 00:15



Je pense que tu devrais utiliser git pull --rebase en collaborant avec d'autres sur la même branche. Vous êtes dans votre travail → commettre → travail → cycle de validation, et lorsque vous décidez de pousser votre travail, votre poussée est rejetée, car il y a eu un travail parallèle sur la même branche. À ce stade, je toujours fait une pull --rebase. Je n'utilise pas squash (pour aplatir les commits), mais je rebase pour éviter les commits de fusion supplémentaires.

Au fur et à mesure que votre connaissance de Git augmente, vous vous trouvez beaucoup plus à l'histoire que tout autre système de contrôle de version que j'ai utilisé. Si vous avez une tonne de petits commits de fusion, il est facile de perdre le focus de l'image plus large qui se passe dans votre histoire.

C'est en fait la seule fois que je fais rebaser (*), et le reste de mon flux de travail est basé sur la fusion. Mais tant que vos committers les plus fréquents font cela, l'histoire semble beaucoup mieux à la fin.

(*) Alors que j'enseignais un cours de Git, un étudiant m'a arrêté à ce sujet, puisque je préconisais aussi de rebaser des branches dans certaines circonstances. Et il avait lu cette réponse;) Un tel rebasement est également possible, mais il doit toujours être conforme à un système préétabli / convenu, et en tant que tel ne devrait pas être «toujours» appliqué. Et à ce moment-là, je ne fais pas d'habitude pull --rebase soit, quelle est la question?)


125
2018-03-18 19:00



Peut-être la meilleure façon de l'expliquer est avec un exemple:

  1. Alice crée une branche de sujet A et travaille dessus
  2. Bob crée une branche B non liée et travaille dessus
  3. Alice fait git checkout master && git pull. Le maître est déjà à jour.
  4. Bob fait git checkout master && git pull. Le maître est déjà à jour.
  5. Alice fait git merge topic-branch-A
  6. Bob fait git merge topic-branch-B
  7. Bob fait git push origin master avant Alice
  8. Alice fait git push origin master, qui est rejetée car il ne s'agit pas d'une fusion rapide.
  9. Alice regarde le journal d'origine / maître, et voit que le commit n'est pas lié au sien.
  10. Alice fait git pull --rebase origin master
  11. Le commit de fusion d'Alice est déroulé, le commit de Bob est tiré, et le commit d'Alice est appliqué après la validation de Bob.
  12. Alice fait git push origin master, et tout le monde est content de ne pas avoir à lire un commit de fusion inutile quand il regarde les logs dans le futur.

Notez que la branche spécifique fusionnée est sans rapport avec l'exemple. Maître dans cet exemple pourrait tout aussi bien être une branche de publication ou une branche de développement. Le point clé est que Alice et Bob fusionnent simultanément leurs branches locales à une branche distante partagée.


113
2018-02-12 08:02



Je ne pense pas qu'il y ait une raison ne pas utiliser pull --rebase - J'ai ajouté du code à Git spécifiquement pour permettre à mon git pull commande de toujours rebaser contre les validations en amont.

Quand on regarde l'histoire, il n'est jamais intéressant de savoir quand le gars / gal qui travaille sur la fonctionnalité s'est arrêté pour se synchroniser. Il pourrait être utile pour le gars / gal pendant qu'il / elle le fait, mais c'est ce que reflog est pour. C'est juste ajouter du bruit pour tout le monde.


39
2018-03-19 08:34



Rappelez-vous juste:

  • tirer = récupérer + fusionner
  • pull --rebase = fetch + rebase

Alors, choisissez la façon dont vous voulez gérer votre branche.

Vous feriez mieux de connaître la différence entre fusion et rebase :)


15
2017-07-08 03:26



Je pense que cela se résume à une préférence personnelle.

Voulez-vous cacher vos erreurs stupides avant de pousser vos changements? Si c'est le cas, git pull --rebase est parfait. Cela vous permet d'écraser plus tard vos commits à quelques (ou un) commits. Si vous avez fusionné dans votre histoire (non bridée), il n'est pas si facile de faire un git rebase plus tard un.

Personnellement, cela ne me dérange pas de publier toutes mes erreurs stupides, donc j'ai tendance à fusionner au lieu de rebaser.


6
2018-03-18 18:19



git pull --rebase peut cacher une réécriture d'histoire d'un collaborateur git push --force. Je recommande d'utiliser git pull --rebase  seulement Si vous savez que vous avez oublié de pousser vos commits avant que quelqu'un d'autre fasse la même chose.

Si vous n'avez rien commis, mais votre espace de travail n'est pas propre, juste git stash avant de git pull. De cette façon, vous ne réécrirez pas en silence votre historique (ce qui pourrait laisser tomber une partie de votre travail).


4
2018-06-19 11:42