Quand est-ce que `git pull --rebase` me mettra dans le pétrin ?

Question

Je comprends que lorsque j'utilise git pull --rebase git va réécrire l'historique et déplacer mes commits locaux pour qu'ils se produisent après tous les commits de la branche d'où je viens de tirer.

Ce que je ne comprends pas, c'est comment cela pourrait être une mauvaise chose. Les gens parlent de s'attirer des ennuis avec git pull --rebase où tu peux te retrouver avec une branche dont les autres ne peuvent pas se servir. Mais je ne comprends pas comment cela est possible puisque tout ce que vous faites est de rejouer vos commits locaux, pas encore publics, par-dessus la branche dont vous avez tiré. Alors, quel est le problème ?

Answer 1

Ce n'est un problème que si vous n'avez publié (poussé) que certains de vos commits, car il serait plus difficile de les fusionner avec d'autres dépôts qui ont déjà ces commits. Puisque leur SHA1 a changé, Git essaiera de les rejouer. à nouveau sur ces dépôts.

Si vous n'avez pas repoussé l'un de ces commits, tout rebasement devrait être sûr.

Donc la question ici est : êtes-vous sûr que tous les commit locaux que vous rebasez sont toujours réellement... locaux ?
Et vous êtes sûr de ça ? git pull --rebase après git pull --rebase ' ?

Si vous travaillez sur une "branche privée" (une branche que vous n'avez jamais poussée, mais seulement fusionnée ou rebasée sur une branche publique, que vous pousserez), vous pouvez rebaser cette branche privée quand vous le souhaitez.

En fin de compte, tout dépend de la flux de travail de la fusion vous avez choisi d'établir .

Answer 2

S'engager dans une branche. Pousser. Fusionner vers une autre branche (disons que vous maintenez deux lignes de base, une branche patch et une branche nouveau-développement). Réalisez que d'autres commits ont été poussés vers la branche serveur que vous suivez. pull --rebase. Soudainement, vous avez refait chacun des commits avec le nouveau hash - et détruit le commit de fusion.

Answer 3

Si personne ne s'est inspiré de vous, et que vous n'avez pas poussé vos commits (avant rebasement) ailleurs, alors vous êtes théoriquement OK. Cependant, Git est conçu pour bien gérer les fusions et vous pouvez trouver qu'il y a moins de travail en général si vous tirez et fusionnez au lieu de tirer et rebaser.

Answer 4

Rappelez-vous que Git est un distribué système de contrôle des sources. Les utilisateurs n'ont pas à extraire les données du dépôt central vers lequel vous les poussez. Dans certains flux de travail, ils peuvent extraire leurs modifications directement de vous. Dans ces cas, la réécriture de votre historique peut certainement causer les problèmes dont vous parlez.