Git rebase : tout ce que vous devez savoir
La commande Git rebase déplace une branche vers un nouvel emplacement à la tête d’une autre branche. Contrairement à la commande Git merge, rebase implique la réécriture de l’historique de votre projet. C’est un excellent outil, mais ne rebasez pas les commits sur lesquels d’autres développeurs ont basé leur travail.
Le connard rebase La commande combine deux branches de code source en une seule. Le connard merge la commande le fait aussi. Nous expliquons ce que rebase fait, comment il est utilisé et quand l’utiliser merge Au lieu.
Sommaire
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.
Le connard rebase La commande est un autre moyen de transférer les modifications d’une branche à une autre. La merge et rebase Les commandes ont des objectifs similaires, mais elles atteignent leurs fins de différentes manières et donnent des résultats légèrement différents.
Qu’est-ce que la fusion Git ?
Alors qu’est-ce que le Git merge commande pour? 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. Maintenant, vous voulez envoyer votre nouvelle fonctionnalité au master bifurquer. Vous devez être dans le master branche pour en fusionner une autre.
Nous pouvons nous assurer que nous sommes dans le master branche en la vérifiant explicitement avant de fusionner.
git checkout master
Nous pouvons maintenant dire à Git de fusionner les dev-branch dans la branche actuelle, qui est la master bifurquer.
git merge dev-branch
Notre merge est terminé pour nous. Si vous passez à la caisse master branch et compilez-le, il contiendra la fonctionnalité nouvellement 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 le master et dev-branch branches, et le commit dans le master succursale juste avant le dev-branch a été créé. Il effectue ensuite un commit sur le master bifurquer.
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 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 la branche a été incorporée dans master bifurquer.
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 le master branche, 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 stash La commande stocke vos modifications non validées pour vous et vous permet de les rappeler avec stash pop .
Vous les utiliseriez comme ceci :
stash git merge dev-branch stash 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 ?
Le connard rebase commande 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 succursale appelée dev-branch et nous voulons déplacer ces changements vers le master bifurquer.
Après le rebase cela ressemble à une chronologie unique et complètement linéaire des modifications.
La dev-branch a été supprimé, et les commits dans le dev-branch ont été ajoutés à la branche master. Le résultat final est le même que si les commits dans le dev-branch avait en fait été directement engagé dans la master branche en premier lieu. Les commits ne sont pas simplement ajoutés au master branche, ils sont « rejoués » et ajoutés frais.
C’est pourquoi le rebase commande est considérée comme destructrice. 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 le 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 git rebase Exemple. Nous avons un projet avec une branche appelée new-feature. Épouser rebase cette branche sur le master branche comme celle-ci.
Dans un premier temps, nous vérifions que le master branche n’a pas de modifications en suspens.
git status
Nous vérifions le new-feature bifurquer.
git checkout new-feature
Nous disons à Git de rebase la branche courante sur la branche master.
git rebase master
Nous pouvons voir que nous avons encore deux branches.
git branch
Nous revenons au master bifurquer
git checkout master
Nous fusionnons la branche nouvelle fonctionnalité dans la branche actuelle, qui dans notre cas est la branche master bifurquer.
git merge new-feature
Fait intéressant, nous avons encore deux succursales après la fusion finale.
La différence, c’est que maintenant le chef du new-feature branche et le chef de la master branche sont définies pour pointer vers le même commit, et l’historique Git ne montre pas qu’il y avait autrefois une branche distincte new-feature branche, à l’exception de l’étiquette de la branche.
Git Rebase vs Merge : Lequel devriez-vous utiliser ?
Il ne s’agit pas de rebase contre. merge. Ce sont deux commandes puissantes et vous les utiliserez probablement toutes les deux. Cela dit, il existe des cas d’utilisation où rebase ne fonctionne pas vraiment bien. Décocher les erreurs causées par des erreurs en utilisant merge sont désagréables, mais les erreurs de décrochage 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 avec rebase c’est désastreux. Tu pourrais encore rebase dans le mauvais sens par exemple, et rebase votre branche master sur votre new-feature bifurquer. Pour obtenir votre master rebranchez-vous, vous devrez rebase encore une fois, cette fois de votre new-feature succursale à votre master bifurquer. Cela restaurerait votre master branche, mais avec une histoire étrange.
Ne pas utiliser rebase sur des succursales 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 local référentiel, 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 de regarder vos commits, ce qui signifie que ces changements sont sur une branche publique, même s’ils ne sont pas sur le master bifurquer.
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 ont peut-être déjà basé leur travail sur ces commits. Votre local rebase 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 un désordre merge 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 pourrait être interdit dans votre projet. Il peut y avoir des objections culturelles locales. Certains projets ou organisations considèrent 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é. Alors, rebase pourrait être hors de la table.
Mais, utilisé localement, sur des branches privées, rebase est un outil utile.
Pousser après vous avez rebasé 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.
