La règle avec git est que vous ne devriez jamais tenter de modifier l’historique après avoir été partagé / publié / poussé. Vous pouvez le faire, bien sûr, si vous voulez vraiment avoir des permissions suffisantes, mais cela doit être fait avec beaucoup de soin car cela peut gâcher les autres.

Heureusement, quand vous avez un déploiement typique de git avec un seul repository en amont (origine) qui est la source de tout ce qui est bon et vrai dans l’univers, vous pouvez utiliser git pull --rebase au git pull --rebase de votre coeur et ce sera parfaitement sûr et à mon avis, vous donner une histoire beaucoup plus saine (ce qui signifie linéaire). Moi et mon équipe l’utilisons continuellement.

Cependant, si vous commencez à avoir plusieurs télécommandes et commencez à faire git pull --rebase pour ne plus avoir à effectuer de rebasage avec la même cible, ou commencez à pousser votre twig vers d’autres référentiels avant de git pull --rebase avec votre primaire en amont – vous pouvez alors commencer à rencontrer des problèmes. Chaque fois que vous partagez vos modifications avec un autre répertoire distant et que vous modifiez ces modifications (pour les valeurs de modification équivalant à la modification du SHA / parent / etc, même si le message / contenu de validation n’a pas changé), eu les anciens changements.

Tant que vous ne sortez pas de l’enveloppe de rebase, git pull --rebase sera très bon pour vous.

Cela, erreur, ne répond pas à la question sur la différence entre git pull --rebase et git fetch && git rebase @{u} Je vais juste aller de l’avant et dire que je ne connais aucune différence et s’il y en a une, c’est assez subtil que je ne l’ai pas remarqué dans les années où j’ai utilisé git. Peut-être que le système détermine le bon répertoire que votre twig doit récupérer si vous avez plusieurs référentiels et que “origine” n’est pas en amont de cette twig?

Et même si vous ne parvenez pas à maîsortingser git-rebase, vous pouvez bien sûr retrouver facilement votre environnement de pré-rebase d’origine avec git log -g et / ou git reset --hard ORIG_HEAD . Il suffit de ne pas forcer les poussées (interdit par défaut dans presque tous les serveurs git) et vous serez heureux.

ÉDITÉ

Avec le temps, ma compréhension s’est élargie. git pull --rebase appelle git rebase pour faire le travail de rebase, donc en ce sens il n’y a pas de différence entre eux. Cependant, git-pull appelle en fait git rebase --onto @{u} $(git merge-base HEAD @{u}@{1}) OK, cette syntaxe (“@ {u} @ {1}”) est peut-être un peu opaque et une simplification au démarrage, mais le fait est qu’il découvre ce que la base de fusion était en amont AVANT de lancer la commande fetch. Quelle différence cela fait-il, vous demandez? Eh bien, dans le cas normal aucun. Cependant, si vous changez de site vers l’amont ou si l’amont lui-même a été rebasé, cela peut être très important. Si upstream a été réécrit et que vous avez fait un git rebase @{u} vous pourriez être très mécontent et recevoir des doubles-commits ou des conflits en fonction de la réécriture des anciens commits. Cependant, avec la magie derrière git pull --rebase seuls les commits qui sont les vôtres et les vôtres seront appliqués au-dessus de @ {u}.

OK, c’est aussi une simplification. Si upstream a fait un rebase à partir de 100 commits (mais il y a en fait 101+ commits dans l’historique) et que vous avez fait une git fetch avant de git pull --rebase alors git ne sera pas capable de déterminer -base devait déterminer quels sont vos commits locaux. Le résultat de ceci est que git fetch considéré comme dangereux (lorsque vous avez des commits locaux et que l’amont est réécrit). Cependant, la véritable règle générale est de “ne jamais tenter de modifier l’historique après le partage / la publication / la diffusion”, ce qui a été mon sharepoint départ.

TL; DR:

git fetch considéré comme dangereux (utilisez donc git pull --rebase ); et ne jamais essayer de changer l’histoire après avoir été partagé / publié / poussé (parce qu’entre autres choses, git fetch sera dangereux).

La vérité est qu’ils SONT différents. Voici une page Web vraiment utile qui explique tout cela avec brio:

http://gitolite.com/git-pull–rebase.html

Donc git pull --rebase a une magie significative sur git fetch; git rebase git fetch; git rebase qui la plupart du temps vous ne remarquerez pas, mais dans les cas où le responsable de la maintenance a ignoré tous ces avertissements sévères et décidé de réécrire l’historique d’une twig publique, il peut vraiment aider en consultant votre refog local et en faisant la rebase locale d’une manière plus intelligente.

Cela dit, il s’agit toujours d’un rebase, alors vous réécrivez toujours l’histoire! Par conséquent, tous les avertissements sévères standard s’appliquent toujours. Mais si vous travaillez sur une twig privée (c’est-à-dire non publiée), alors ça va.

Je vais en dire un peu plus sur les avertissements sévères. Ils sont valides, mais personnellement, je trouve que la plupart des gens sont un peu trop paranoïaques à propos de la rébellion, comme un git rebase dans leur chambre au milieu de la nuit quand ils étaient jeunes et mangeaient leur sœur. Ce ne devrait vraiment pas être si effrayant:

• si c’est une twig privée, rebassez vous au contenu de votre coeur
• S’il s’agit d’une succursale publique, ne vous rebassez pas à moins que vous ne deviez vraiment le faire, et si vous le faites, assurez-vous de comprendre l’impact et assurez-vous que toute personne susceptible d’être touchée est correctement informée. obtenir une mauvaise surprise et perdre un temps fou à comprendre ce qui s’est passé.

C’est si simple. Et oui, j’irais même jusqu’à encourager activement les gens à git rebase -i régulièrement git rebase -i sur leurs twigs privées. Polir l’historique avant de passer à un site public / en amont est une bonne chose , car personne ne veut parcourir l’histoire d’un projet qui est plein de commits comme «oops», en corrigeant une erreur de 3 commits. (OTOH, ne soyez pas totalement obsédé par le rebasement en quête d’une histoire sans faille. Nous sums humains. Nous faisons des erreurs. Traitez-le.)

Une dernière observation concernant le git pull --rebase magie. Si la twig publique en amont a été rebasée de manière sensée (par exemple, écrasement / correction de commits ou suppression de commits qui n’auraient pas dû être placés), alors la magie fonctionne en votre faveur. Toutefois, si le rebase en amont a été accidentellement abandonné , la magie vous empêchera de les remettre en silence. Dans ce cas, si vous souhaitez remettre ces commits supprimés, vous devriez plutôt utiliser git fetch; git rebase git fetch; git rebase .

Outre la mise à jour de votre twig locale depuis sa twig de suivi à distance, l’option -pull met à jour vos fichiers d’espace de travail.

Donc, il est probablement plus courant de lancer git -rebase (ou de configurer pull pour utiliser rebase par défaut) que de récupérer git; Git rebase.