Quand dois-je utiliser git pull --rebase ?

Question

Je connais des gens qui utilisent git pull --rebase par défaut et d'autres qui insistent pour ne jamais l'utiliser. Je crois que je comprends la différence entre fusion et rebasage, mais j'essaie de placer cela dans le contexte de git pull . S'agit-il simplement de ne pas vouloir voir un grand nombre de messages de validation de fusion, ou y a-t-il d'autres problèmes ?

Answer 1

J'aimerais donner une perspective différente sur ce que signifie réellement "git pull --rebase", car il semble que cela soit parfois perdu.

Si vous avez déjà utilisé Subversion (ou CVS), vous êtes peut-être habitué au comportement de "svn update". Si vous avez des changements à livrer et que la livraison échoue parce que des changements ont été faits en amont, vous faites "svn update". Subversion procède en fusionnant les changements en amont avec les vôtres, ce qui peut entraîner des conflits.

Ce que Subversion vient de faire, était essentiellement "pull --rebase". L'acte de reformuler vos changements locaux pour qu'ils soient relatifs à la nouvelle version est la partie " rebasement ". Si vous avez fait "svn diff" avant la tentative de livraison ratée, et que vous comparez la différence résultante avec la sortie de "svn diff" après, la différence entre les deux différences 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" modifications n'existent que sous forme de modifications non-committées dans votre copie de travail, alors que dans Git vous avez des commits réels localement. En d'autres termes, dans Git vous avez bifurqué l'historique ; votre historique et l'historique amont ont divergé, mais vous avez un ancêtre commun.

À mon avis, dans le cas normal où votre branche locale reflète simplement la branche amont et où vous effectuez un développement continu sur celle-ci, la bonne chose à faire est toujours "--rebase", car c'est ce que vous êtes sémantiquement en réalité. en faisant . Vous et d'autres s'attaquent à l'histoire linéaire prévue d'une branche. Le fait que quelqu'un d'autre ait poussé un peu avant votre tentative de poussée n'est pas pertinent, et il semble contre-productif que chaque accident de timing de ce type entraîne des fusions dans l'historique.

Si vous ressentez réellement le besoin que quelque chose soit une branche pour une raison quelconque, c'est une autre préoccupation à 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 tenir compte des autres personnes qui doivent observer et comprendre l'histoire de votre projet. Voulez-vous que l'histoire soit jonchée de centaines de fusions partout, ou voulez-vous seulement les quelques fusions qui représentent de véritables fusions d'efforts de développement intentionnellement divergents ?

Answer 2

Vous devez utiliser git pull --rebase quand

• vos changements ne méritent pas une branche séparée

En effet, pourquoi pas ? C'est plus clair, et ça n'impose pas une regroupement logique sur vos commits.

---

Ok, je suppose que ça nécessite quelques clarifications. Dans Git, comme vous le savez probablement, vous êtes encouragés à faire des branches et des fusions. Votre branche locale, dans laquelle vous tirez les changements, et votre branche distante sont, en fait, des branches différentes, et git pull est de les fusionner. C'est raisonnable, car vous ne poussez pas très souvent et accumulez généralement un certain nombre de modifications avant qu'elles ne constituent une fonctionnalité achevée.

Cependant, parfois, quelle qu'en soit la raison, vous pensez qu'il serait préférable que ces deux éléments, distant et local, soient un branche. Comme dans SVN. C'est ici que git pull --rebase entre en jeu. On ne fusionne plus, on commettre sur la branche distante . C'est de cela qu'il s'agit en fait.

La question de savoir si c'est dangereux ou non est celle de savoir si vous traitez la branche locale et la branche distante comme une chose indissociable. 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, cela ne l'est pas (lorsque vous auriez normalement créé une autre branche, mais que vous êtes trop paresseux pour le faire). Mais c'est une autre question.

Answer 3

Je pense que vous devriez utiliser git pull --rebase lorsque vous collaborez avec d'autres personnes sur la même branche. Vous êtes dans votre cycle de travail commit work commit, et quand 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 moment-là, je toujours faire un pull --rebase . Je n'utilise pas squash (pour aplanir 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 retrouvez à regarder beaucoup plus l'historique qu'avec les autres systèmes de contrôle de version que j'ai utilisés. Si vous avez une tonne de petits commits de fusion, il est facile de perdre de vue l'image globale qui se passe dans votre historique.

C'est en fait la seule fois où je fais du rebasement(*), et le reste de mon flux de travail est basé sur la fusion. Mais tant que vos committers les plus fréquents le font, l'histoire est bien meilleure à la fin.

(*) Alors que j'enseignais un cours sur Git, un étudiant m'a arrêté sur ce point, car je préconisais également le rebasage des branches de fonctionnalités dans certaines circonstances. Et il avait lu cette réponse ;) Un tel rebasage est également possible, mais il doit toujours se faire selon un système pré-établi/convenu, et en tant que tel ne devrait pas être appliqué "toujours". Et à ce moment-là, je ne fais généralement pas de pull --rebase soit, ce qui est l'objet de la question ;)

Answer 4

Je ne pense pas qu'il y ait jamais de raison no à utiliser pull --rebase -- J'ai ajouté un code à Git spécifiquement pour permettre à mes git pull pour toujours rebaser sur les commits amont.

Lorsque l'on regarde l'histoire, il n'est jamais intéressant de savoir quand l'homme ou la femme qui travaillait sur le projet s'est arrêté pour se synchroniser. Cela peut être utile pour le gars/la fille pendant qu'il/elle le fait, mais c'est ce qu'il/elle fait. reflog est pour. C'est juste ajouter du bruit pour tous les autres.

Answer 5

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. Il vous permet de réduire ultérieurement vos commits à quelques (ou un) commits. Si vous avez des fusions dans votre historique (non poussé), il n'est pas si facile de faire un git rebase plus tard.

Personnellement, cela ne me dérange pas de publier toutes mes erreurs stupides, c'est pourquoi j'ai tendance à fusionner plutôt qu'à rebaser.