Articles

pourquoi vous devriez arrêter D’utiliser git rebase

Posted by admin

Après avoir utilisé Git pendant plusieurs années, je me suis retrouvé à utiliser progressivement des commandes Git de plus en plus avancées dans le cadre de mon flux de travail quotidien. Peu de temps après avoir découvert git rebase, Je l’ai rapidement intégré dans Mon flux de travail quotidien. Ceux qui connaissent le rebasage savent à quel point c’est un outil puissant et à quel point il est tentant de l’utiliser tout le temps. Cependant, j’ai vite découvert que le rebasage présente des défis qui ne sont pas évidents lorsque vous commencez à le faire. Avant de les présenter, je vais rapidement récapituler les différences entre la fusion et le rebasage.,

considérons d’abord l’exemple de base où vous souhaitez intégrer une branche de fonctionnalité avec master. En fusionnant, nous créons un nouveau commitg qui représente la fusion entre les deux branches. Le graphique de validation montre clairement ce qui s’est passé, et nous pouvons voir les contours du graphique « train track » familier des plus grands git-repos.,

Example of merging

Alternatively, we could rebase before merging. The commits are removed and the feature branch is reset to master, after which the commits are re-applied on top of feature., Les différences de ces commits réappliqués sont généralement identiques à leurs homologues d’origine, mais ils ont des commits parents différents, et donc des clés SHA-1 différentes.

Exemple de relocalisation

Nous avons maintenant changé la base de commettre de feature à partir de b de c, littéralement re-fonder., Merging feature to masteris now a fast-forward merge, because all commits on feature are direct descendants of master.

Example of fast-forward merging

Compared to the merge approach, the resulting history is linear with no divergent branches., La lisibilité améliorée était la raison pour laquelle je préférais rebaser les branches avant de fusionner, et je m’attends à ce que ce soit également le cas pour d’autres développeurs.

cependant, cette approche comporte des défis qui peuvent ne pas être évidents.

considérons le cas où une dépendance encore utilisée surfeature a été supprimée surmaster. Lorsque featureest rebasé sur master, le premier commit réappliqué cassera votre build, mais tant qu’il n’y a pas de conflits de fusion, le processus de rebase continuera sans interruption., L’erreur du premier commit restera présente dans tous les commits suivants, entraînant une chaîne de commits cassés.

cette erreur n’est découverte qu’après la fin du processus de rebase, et est généralement corrigée en appliquant un nouveau commit de correction de bugg en haut.,

Exemple de l’échec de la relocalisation

Si vous avez des conflits lors de la relocalisation cependant, Git va faire une pause sur le conflit s’engager, vous permettant de résoudre le conflit avant de continuer. Résoudre des conflits au milieu du rebasage d’une longue chaîne de commits est souvent déroutant, difficile à obtenir, et une autre source d’erreurs potentielles.

L’Introduction d’erreurs est particulièrement problématique lorsque cela se produit lors du rebasage., De cette façon, de nouvelles erreurs sont introduites lorsque vous réécrivez l’historique, et elles peuvent masquer de véritables bogues qui ont été introduits lors de la première écriture de l’historique. En particulier, cela rendra plus difficile L’utilisation de git bisect, sans doute l’outil de débogage le plus puissant de la boîte à outils Git. À titre d’exemple, considérez la branche de fonctionnalité suivante. Disons que nous avons introduit un bug vers la fin de la branche.,

Une branche avec des bugs introduits vers la fin

Vous ne pouvez pas découvrir ce bug jusqu’semaines après que la branche a été fusionné à la balise master. Pour trouver le commit qui a introduit le bogue, vous devrez peut-être rechercher des dizaines ou des centaines de commits., Ce processus peut être automatisé en écrivant un script qui teste la présence du bogue, et en l’exécutant automatiquement via Git bisect, en utilisant la commande git bisect run <yourtest.sh>.

Bisect effectue une recherche de bissection dans l’historique, identifiant le commit qui a introduit le bogue. Dans l’exemple ci-dessous, il réussit à trouver le premier commit défectueux, car tous les commits cassés contiennent le bogue réel que nous recherchons.,

Example of successfull Git bisect

On the other hand, if we’ve introduced additional broken commits during rebasing (here, d and e), bisect will run into trouble., Dans ce cas, nous espérons que git identifie commit f comme le mauvais, mais il identifie par erreur dà la place, car il contient une autre erreur qui casse le test.

Exemple de l’échec d’un Git coupent

Ce problème est plus grand qu’il ne paraît au premier abord.

Pourquoi utilisons-nous Git du tout?, Parce que c’est notre outil le plus important pour traquer la source de bogues dans notre code. Git est notre filet de sécurité. En rebasant, nous donnons moins de priorité, au profit de la volonté de réaliser une histoire linéaire.

Il y a quelque temps, j’ai dû parcourir plusieurs centaines de commits pour traquer un bogue dans notre système. Le commit défectueux était situé au milieu d’une longue chaîne de commits qui n’ont pas été compilés, en raison d’un rebase défectueux effectué par un collègue. Cette erreur inutile et totalement évitable m’a amené à passer près d’une journée supplémentaire à traquer le commit.,

alors, comment pouvons-nous éviter ces chaînes de commits cassés lors du rebasage? Une approche pourrait être de laisser le processus de rebase se terminer, de tester le code pour identifier les bogues et de revenir dans l’histoire pour corriger les bogues où ils ont été introduits. À cette fin, nous pourrions utiliser le rebasage interactif.

Une autre approche serait de mettre Git en pause à chaque étape du processus de rebase, de tester les bugs et de les corriger immédiatement avant de continuer.

c’est un processus lourd et sujet aux erreurs, et la seule raison de le faire serait de réaliser un historique linéaire. Existe-t-il un moyen plus simple et meilleur?,

Il y a; git merge. C’est un processus simple en une étape, où tous les conflits sont résolus en un seul commit. Le commit de fusion qui en résulte marque clairement le point d’intégration entre nos branches, et notre histoire décrit ce qui s’est réellement passé et quand cela s’est produit.

l’importance de garder votre histoire vraie ne doit pas être sous-estimée. En rebasant, vous mentez à vous-même et à votre équipe. Vous prétendez que les commits ont été écrits aujourd’hui, alors qu’ils l’ont été en fait hier, sur la base d’un autre commit., Vous avez sorti les commits de leur contexte d’origine, déguisant ce qui s’est réellement passé. Pouvez-vous être sûr que le code se construit? Pouvez-vous être sûr que les messages de validation ont toujours un sens? Vous pouvez croire que vous nettoyez et clarifiez votre histoire, mais le résultat peut très bien être le contraire.

il est impossible de dire quelles erreurs et défis l’avenir apporte pour votre base de code. Cependant, vous pouvez être certain qu’une histoire vraie sera plus utile qu’une histoire réécrite (ou fausse).

Leave A Comment