Git rebase : tout ce que vous devez savoir
Publié: 2022-12-15
La commande Git rebase combine deux branches de code source en une seule. La commande Git merge le fait aussi. Nous expliquons ce que fait rebase , comment il est utilisé et quand utiliser merge à la place.
L'explosion des gits
Qu'est-ce que la fusion Git ?
Qu'est-ce que le rebase Git ?
Comment rebaser sur une autre branche
Git Rebase vs Merge : Lequel devriez-vous utiliser ?
Rebaser ou ne pas rebaser ?
L'explosion des gits
Frustré par les autres systèmes de contrôle de version et leurs mises à jour et commits lents, Linus Torvalds, célèbre noyau Linux, a mis de côté un mois en 2005 pour écrire le sien. Il l'a nommé Git.
Des sites comme GitHub, GitLab et BitBucket ont promu et bénéficié de manière symbiotique de Git. Aujourd'hui, Git est utilisé dans le monde entier, avec 98 % des 71 000 répondants à une enquête de 2022 utilisant Git comme système de contrôle de version.
L'une des principales décisions de conception de Git était la vitesse. En particulier, le travail avec les succursales devait être aussi rapide que possible. Les branches sont un élément fondamental des systèmes de contrôle de version. Un référentiel de projet aura une branche principale ou principale. C'est là que se trouve la base de code du projet. Le développement, comme les nouvelles fonctionnalités, a lieu dans des branches latérales séparées. Cela empêche le travail effectué dans les branches de gâcher la branche principale et permet un développement simultané dans différentes parties de la base de code.
Au fur et à mesure que les développements dans les branches latérales sont terminés, les modifications sont transférées vers la branche principale en fusionnant la branche de développement dans la branche principale. Dans d'autres systèmes de contrôle de version, travailler avec des branches était difficile et coûteux en calculs. Travailler avec des branches dans Git est très rapide et très léger. Ce qui était autrefois un exercice fastidieux et souvent évité dans d'autres systèmes, est devenu trivial dans Git.
La commande Git rebase est un autre moyen de transférer les modifications d'une branche à une autre. Les commandes merge et rebase ont des objectifs similaires, mais elles atteignent leurs objectifs de manière différente et donnent des résultats légèrement différents.
Qu'est-ce que la fusion Git ?
Alors à quoi sert la commande Git merge ? Disons que vous avez créé une branche appelée dev-branch pour travailler sur une nouvelle fonctionnalité.
Vous faites quelques commits et testez votre nouvelle fonctionnalité. Tout fonctionne bien. Vous souhaitez maintenant envoyer votre nouvelle fonctionnalité à la branche master . Vous devez être dans la branche master pour en fusionner une autre.
Nous pouvons nous assurer que nous sommes dans la branche master en la vérifiant explicitement avant de fusionner.
maître de caisse git
Nous pouvons maintenant dire à Git de fusionner la dev-branch dans la branche actuelle, qui est la branche master .
git merge dev-branch
Notre merge est terminée pour nous. Si vous extrayez la branche master et que vous la compilez, elle contiendra la nouvelle fonctionnalité développée. Ce que Git a réellement réalisé est une fusion à trois voies. il compare les commits les plus récents dans les branches master et dev-branch , et le commit dans la branche master juste avant la création de la dev-branch . Il effectue ensuite un commit sur la branche master .
Les fusions sont considérées comme non destructives car elles ne suppriment rien et ne modifient en rien l'historique de Git. La dev-branch développement existe toujours et aucun des commits précédents n'est modifié. Un nouveau commit est créé qui capture les résultats de la fusion à trois.
Après la fusion, notre référentiel Git ressemble à une chronologie avec une ligne alternative bifurquant puis revenant à la chronologie principale.
La dev-branch a été intégrée à la branche master .
Si vous avez beaucoup de branches dans un projet, l'historique du projet peut devenir déroutant. C'est souvent le cas si un projet compte de nombreux contributeurs. Étant donné que l'effort de développement se divise en plusieurs voies différentes, l'historique du développement n'est pas linéaire. Démêler l'historique des commits devient encore plus difficile si les branches ont leurs propres branches.
Notez que si vous avez des modifications non validées dans la branche master , vous devrez faire quelque chose avec ces modifications avant de pouvoir y fusionner quoi que ce soit. Vous pouvez créer une nouvelle branche et y valider les modifications, puis effectuer la fusion. Vous devrez ensuite fusionner votre branche temporaire dans la branche principale.
Cela fonctionne, mais Git a une commande qui réalise la même chose, sans avoir à créer de nouvelles branches. La commande stash stocke vos modifications non validées pour vous et vous permet de les rappeler avec stash pop .
Vous les utiliseriez comme ceci :
planque git merge dev-branch cachette pop
Le résultat final est une branche fusionnée, avec vos modifications non enregistrées restaurées.
Qu'est-ce que le rebase Git ?
La commande Git rebase atteint ses objectifs d'une manière complètement différente. Il prend tous les commits de la branche sur laquelle vous allez rebaser et les rejoue à la fin de la branche sur laquelle vous rebasez.
En reprenant notre exemple précédent, avant d'effectuer toute action, notre référentiel Git ressemble à ceci. Nous avons une branche appelée dev-branch et nous voulons déplacer ces modifications vers la branche master .
Après le rebase , cela ressemble à une chronologie unique et complètement linéaire des changements.
La dev-branch a été supprimée et les commits de la dev-branch ont été ajoutés à la branche master. Le résultat final est le même que si les commits dans la dev-branch avaient été directement commités dans la branche master en premier lieu. Les commits ne sont pas simplement ajoutés à la branche master , ils sont "rejoués" et ajoutés frais.
C'est pourquoi la commande rebase est considérée comme destructive. La branche rebasée n'existe plus en tant que branche distincte et l'historique Git de votre projet a été réécrit. Vous ne pouvez pas déterminer ultérieurement quels commits ont été initialement effectués sur dev-branch .
Cependant, cela vous laisse un historique simplifié et linéaire. Comparé à un référentiel avec des dizaines voire des centaines de branches et de fusions, la lecture du journal Git ou l'utilisation d'une interface graphique git pour consulter un graphique du référentiel, un référentiel rebasé est un jeu d'enfant à comprendre.
Comment rebaser sur une autre branche
Essayons un exemple de git rebase . Nous avons un projet avec une branche appelée new-feature . Nous rebase cette branche sur la branche master comme ceci.
Tout d'abord, nous vérifions que la branche master n'a pas de modifications en suspens.
statut git
Nous vérifions la branche des new-feature .
git checkout nouvelle fonctionnalité
Nous disons à Git de rebase la branche actuelle sur la branche master.
maître de rebase git
Nous pouvons voir que nous avons encore deux branches.
branche git
Nous retournons à la branche master
maître de caisse git
Nous fusionnons la branche new-feature dans la branche current, qui dans notre cas est la branche master .
git merge nouvelle fonctionnalité
Fait intéressant, nous avons encore deux succursales après la fusion finale.
La différence est que maintenant la tête de la branche new-feature et la tête de la branche master sont définies pour pointer vers le même commit, et l'historique Git ne montre pas qu'il y avait une branche new-feature distincte, à part l'étiquette de la branche.
Git Rebase vs Merge : Lequel devriez-vous utiliser ?
Ce n'est pas un cas de rebase vs. merge . Ce sont deux commandes puissantes et vous les utiliserez probablement toutes les deux. Cela dit, il y a des cas d'utilisation où rebase ne fonctionne pas vraiment bien. Décocher les erreurs causées par des erreurs utilisant la merge est désagréable, mais décocher les erreurs causées par rebase est infernal.
Si vous êtes le seul développeur à utiliser un référentiel, il y a moins de chances que vous fassiez quelque chose de désastreux avec rebase . Vous pouvez toujours rebase dans la mauvaise direction par exemple, et rebase votre branche master sur votre branche new-feature . Pour récupérer votre branche master , vous devrez rebase à nouveau, cette fois de votre branche new-feature vers votre branche master . Cela restaurerait votre branche master , mais avec un historique étrange.
N'utilisez pas le rebase sur des branches partagées où d'autres sont susceptibles de travailler. Vos modifications apportées à votre référentiel vont causer des problèmes à de nombreuses personnes lorsque vous pousserez votre code rebasé vers votre référentiel distant.
Si votre projet a plusieurs contributeurs, la chose la plus sûre à faire est d'utiliser uniquement rebase sur votre référentiel local , et non sur les branches publiques. De même, si les demandes d'extraction font partie de vos revues de code, n'utilisez pas rebase . Ou du moins, n'utilisez pas rebase après avoir créé la demande d'extraction. D'autres développeurs sont susceptibles d'examiner vos commits, ce qui signifie que ces modifications se trouvent sur une branche publique, même si elles ne se trouvent pas sur la branche master .
Le danger est que vous allez rebase commits qui ont déjà été poussés vers un référentiel distant, et d'autres développeurs pourraient avoir déjà basé leur travail sur ces commits. Votre rebase locale fera disparaître ces commits existants. Si vous poussez ces modifications dans le référentiel, vous ne serez pas populaire.
Les autres contributeurs devront passer par une merge désordonnée pour que leur travail soit repoussé vers le référentiel. Si vous récupérez ensuite leurs modifications dans votre référentiel local, vous êtes alors confronté à la suppression d'un tas de modifications en double.
Rebaser ou ne pas rebaser ?
Rebase peut être interdit dans votre projet. Il peut y avoir des objections culturelles locales. Certains projets ou organisations considèrent le rebase comme une forme d'hérésie et un acte de profanation. Certaines personnes pensent que l'historique Git devrait être un enregistrement inviolable et permanent de ce qui s'est passé. Donc, rebase pourrait être hors de propos.
Mais, utilisé localement, sur des branches privées, le rebase est un outil utile.
Poussez après avoir changé de base et limitez-le aux branches où vous êtes le seul développeur. Ou du moins, là où tout développement s'est arrêté et où personne d'autre n'a basé d'autre travail sur les commits de votre branche.
Faites-le et vous éviterez tout problème.
CONNEXION : Comment vérifier et mettre à jour votre version de Git