Phenquestions
Les débutants de Git sont mis en garde contre la commande rebase. Et à juste titre. Avec toutes les nouvelles choses à apprendre, les débutants ont probablement intérêt à maîtriser les concepts de base avant de se plonger dans les subtilités du rebasage. Cependant, si vous comprenez les bases de la fusion de branches, alors savoir comment rebaser peut vous aider à résoudre des énigmes de développement compliquées au bon moment.
Git Rebase : définitions
Selon la documentation git, la commande rebase réappliquera les commits au-dessus d'un autre conseil de base. Cette définition peut être un peu intimidante. Il est plus facile d'expliquer le rebase comme une procédure qui ajoute les modifications de la branche actuelle à la queue d'une autre branche. Passons en revue un exemple pour avoir une meilleure idée de ce qui se passe.
Exemple de rebasage de Git
Dans cet exemple, nous allons d'abord créer un cas de test avec les branches 'master' et 'feature'. Ensuite, nous ferons une fusion standard. Ensuite, nous allons recréer le scénario de test et effectuer un rebase et une fusion.
1. Création de branches principales et de fonctions
Voici le scénario que nous allons créer :
A - B - C (maître) \ E - F (fonctionnalité)
Dans l'exemple ci-dessus, nous prenons le chemin suivant :
- Commit A : nous ajoutons un.txt dans la branche 'master'
- Commit B : on ajoute b.txt dans la branche 'master'
- A ce stade, nous créons la branche 'feature' ce qui signifie qu'elle aura un.txt et b.SMS
- Commit C : on ajoute c.txt dans la branche 'master'
- Nous allons à la branche « fonctionnalité »
- Commit E : nous modifions un.txt dans la branche 'fonctionnalité'
- Commit F : on modifie b.txt dans la branche 'fonctionnalité'
Vous pouvez créer un dossier et exécuter le code suivant dans le dossier pour créer la situation ci-dessus :
git init toucher un.txt git add -A git commit -m "Commit A : a ajouté un.txt" touche b.txt git add -A git commit -m "Commit B: ajouté b.txt" git branch fonctionnalité touch c.txt git add -A git commit -m "Commit C: ajouté c.txt" git status git checkout fonctionnalité echo aaa > a.txt git add -A git commit -m "Commit E: a modifié un.txt" echo bbb > b.txt git add -A git commit -m "Commit F: modifié b.SMS"
2. Fusion simple
Utilisons la commande log pour vérifier les deux branches.
Résultats pour 'maître' :
$ git checkout master Basculé vers la branche 'master' $ git log --oneline 2bbde47 Commit C : ajout c.txt b430ab5 Commit B : ajouté b.txt 6f30e95 Commit A : ajout d'un.txt $ ls a.txtb.txt c.SMS
Résultats pour « fonctionnalité » :
$ git checkout feature Basculé vers la branche 'feature' $ git log --oneline 0286690 Commit F : modifié b.txt 7c5c85e Commit E : modification d'un.txt b430ab5 Commit B : ajouté b.txt 6f30e95 Commit A : ajout d'un.txt $ ls a.txtb.SMS
Remarquez comment la branche de fonctionnalité n'a pas Commit C
Maintenant, exécutons la fusion de la branche 'feature' avec la branche 'master'. Il vous sera demandé de saisir un commentaire. Dans le commentaire, ajoutez « Commit G : » au début pour faciliter le suivi.
$ git checkout master Basculement vers la branche 'master' $ git merge fonctionnalité Fusion effectuée par la stratégie 'recursive'. une.txt | 1 + b.txt | 1 + 2 fichiers modifiés, 2 insertions (+)
Résultats pour 'maître' :
$ git checkout master Déjà sur 'master' $ git log --oneline d086ff9 Commit G : Fusionner la branche 'feature' 0286690 Commit F : modifié b.txt 7c5c85e Commit E : modification d'un.txt 2bbde47 Commit C : ajouté c.txt b430ab5 Commit B : ajouté b.txt 6f30e95 Commit A : ajout d'un.txt $ ls a.txtb.txt c.SMS
Résultats pour 'fonctionnalité' :
$ git checkout feature Basculé vers la branche 'feature' $ git log --oneline 0286690 Commit F: modifié b.txt 7c5c85e Commit E : modification d'un.txt b430ab5 Commit B : ajouté b.txt 6f30e95 Commit A : ajout d'un.txt $ ls a.txtb.SMS
Dans la branche 'master', vous remarquerez qu'il y a un nouveau commit G qui a fusionné les changements de la branche 'feature'. Fondamentalement, l'action suivante a eu lieu :
A - B - C - G (maître) \ / E - F (fonctionnalité)
Dans le commit G, toutes les modifications de la branche 'feature' ont été transférées dans la branche master. Mais la branche 'feature' elle-même est restée intacte en raison du processus de fusion. Notez le hachage de chaque commit. Après la fusion, les commits E (7c5c85e) et F (0286690) ont le même hachage sur les branches 'feature' et 'master'.
3. Fusion avec rebasage
Répétons l'étape 1 pour créer à nouveau les branches 'master' et 'feature'.
Résultats pour 'maître' :
$ git checkout master Basculé vers la branche 'master' $ git log --oneline 7f573d8 Commit C : ajout c.txt 795da3c Commit B : ajouté b.txt 0f4ed5b Commit A : ajout d'un.txt $ ls a.txtb.txt c.SMS
Résultats pour 'fonctionnalité' :
$ git checkout feature Basculé vers la branche 'feature' $ git log --oneline 8ed0c4e Commit F : modifié b.txt 6e12b57 Commit E : modification d'un.txt 795da3c Commit B : ajouté b.txt 0f4ed5b Commit A : ajout d'un.txt $ ls a.txtb.SMS
Rebasons à partir de la branche 'feature'.
$ git checkout feature Passage à la branche 'feature' $ git rebase master Tout d'abord, rembobinage de la tête pour rejouer votre travail dessus… Application : Commit E : modification d'un.txt Application : Commit F : modifié b.SMS
Puis fusionnez 'feature' dans 'master'.
$ git checkout master Basculé vers la branche 'master' $ git merge feature Mise à jour 7f573d8… 9efa1a3 Avance rapide a.txt | 1 + b.txt | 1 + 2 fichiers modifiés, 2 insertions (+)
Résultats pour la branche 'master' :
$ git checkout master Déjà sur 'master' $ git log --oneline 9efa1a3 Commit F : modifié b.txt 8710174 Commit E : modifié un.txt 7f573d8 Commit C : ajout c.txt 795da3c Commit B : ajouté b.txt 0f4ed5b Commit A : ajout d'un.txt $ ls a.txtb.txt c.SMS
Résultats pour la branche « fonctionnalité » :
$ git checkout feature Basculé vers la branche 'feature' $ git log --oneline 9efa1a3 Commit F : modifié b.txt 8710174 Commit E : modifié un.txt 7f573d8 Commit C : ajout c.txt 795da3c Commit B : ajouté b.txt 0f4ed5b Commit A : ajout d'un.txt $ ls a.txtb.txt c.SMS
Notez qu'après le rebase et la fusion, les deux branches sont les mêmes. De plus, les hachages pour E et F ont changé dans les deux branches. Fondamentalement, dans le scénario de rebase, voici ce qui s'est passé :
A - B - C \ E' - F' (fonctionnalité, maître)
C'est pourquoi il n'y a pas de nouveau commit. Les commits E et F ont été recalculés et verrouillés à la fin de la branche 'master'.
Le rebasage est un outil utile lorsque vous souhaitez nettoyer l'historique de votre travail. Cependant, il y a un danger qui a donné naissance à la règle d'or.
Règle d'or du rebasage
La règle d'or du rebasage est :
Ne jamais rebaser une branche publique.
Comme vous pouvez le voir dans l'exemple ci-dessus, le rebasage recalcule les commits. Lorsque plusieurs personnes créent des branches à partir d'un référentiel public, le rebasage peut créer des situations où les développeurs qui ont créé de nouvelles branches se retrouveront dans des situations de fusion très compliquées. C'est donc une bonne idée de ne jamais rebaser les branches publiques qui sont partagées.
En conclusion:
Le rebasage est une fonctionnalité unique de Git. Mais à utiliser avec prudence.
Plus d'information:
Voici quelques liens pour une étude plus approfondie :
Documentation Git Rebase
Fusion Atlassian vs rebasage
Les références:
- https://www.atlassien.com/git/tutorials/merging-vs-rebasing
- Contrôle de version avec Git - 07 - Rebase [https://www.Youtube.com/regarder?v=cSf8cO0WB4o]
- https://git-scm.com/docs/git-rebase
- Qu'est-ce que Git rebase? [https://www.Youtube.com/regarder?v=TymF3DpidJ8]
- https://moyen.freecodecamp.org/git-rebase-and-the-golden-rule-explained-70715eccc372
