Tutoriel Git Rebase

Les débutants de Git sont avertis contre le commandement Rebase. Et à juste titre. Avec toutes les nouvelles choses à apprendre, les débutants font probablement mieux de maîtriser les concepts de base avant de se plonger dans les subtilités de la rebas. Cependant, si vous comprenez les bases de la fusion des branches, alors savoir comment réprimander peut vous aider à résoudre des puzzles de développement compliqués lorsque le bon moment vient.

Git Rebase: définitions

Selon la documentation GIT, la commande Rebase se déroulera à l'application du dessus d'une autre pointe de base. Cette définition pourrait être un peu intimidante. Il est plus facile d'expliquer la rébase en tant que procédure qui ajoute les modifications de la branche actuelle à la queue d'une autre branche. Voyons un exemple pour avoir une meilleure idée de ce qui se passe.

Exemple de rebasing Git

Dans cet exemple, nous allons d'abord créer un cas de test avec la branche «maître» et «fonctionnalité». Ensuite, nous ferons une fusion standard. Ensuite, nous recréerons le cas de test et effectuerons la rébase et la fusion.

1. Création de branches de maître et de fonctionnalités

Voici le scénario que nous créerons:

A - b - c (maître)

\

E - F (fonctionnalité)

Dans l'exemple ci-dessus, nous prenons le chemin suivant:

1. Commettre un: nous ajoutons un.Fichier txt dans la branche «maître»

2. Commit B: Nous ajoutons B.Fichier txt dans la branche «maître»

3. À ce stade, nous créons la «fonctionnalité» de la branche qui signifie qu'elle aura un.txt et b.SMS

4. Commit C: Nous ajoutons C.Fichier txt dans la branche «maître»

5. Nous allons à la branche «fonctionnalité»

6. Commit E: Nous modifions un.Txt dans la branche «fonctionnalité»

7. Commit F: Nous modifions B.Txt dans la branche «fonctionnalité»

Vous pouvez créer un dossier et exécuter le code suivant à l'intérieur du dossier pour créer la situation ci-dessus:

git init
toucher un.SMS
git add -a
git commit -m "engager un: ajouter un.SMS"
toucher b.SMS
git add -a
git commit -m "commit b: ajouté b.SMS"
fonctionnalité de branche git
toucher c.SMS
git add -a
git commit -m "commit c: ajouté c.SMS"
statut git
Fonction de paiement GIT
echo aaa> a.SMS
git add -a
git commit -m "commit e: modifié un.SMS"
écho bbb> b.SMS
git add -a
git commit -m "commit f: modifié b.SMS"

---

2. Fusion simple

Utilisons la commande de journal pour vérifier les deux branches.

Résultats pour «maître»:

$ maître de paiement
Changé de succursale «maître»
$ Git Log --Oneline
2BBDE47 Commit C: Ajouté C.SMS
B430AB5 Commit B: Ajouté B.SMS
6F30E95 COMMISS.SMS
$ ls
un.txt b.txt c.SMS

Résultats pour «fonctionnalité»:

$ GIT CHECKOT FEATTOW
Couché à la «fonctionnalité» de la branche
$ Git Log --Oneline
0286690 Commit F: modifié B.SMS
7C5C85E Commit E: modifié un.SMS
B430AB5 Commit B: Ajouté B.SMS
6F30E95 COMMISS.SMS
$ ls
un.txt b.SMS

Remarquez comment la branche des fonctionnalités n'a pas de validation C

Maintenant, exécutons la branche de fusion «fonctionnalité» avec une branche «maître». Il vous sera demandé de saisir un commentaire. Dans le commentaire, ajoutez «Commit G» »au début pour le rendre plus facile à suivre.

$ maître de paiement
Changé de succursale «maître»
$ git fusiter la fonctionnalité
Fusionner la stratégie «récursive».
un.txt | 1 +
b.txt | 1 +
2 fichiers modifiés, 2 insertions (+)

Résultats pour «maître»:

$ maître de paiement
Déjà sur 'Master'
$ Git Log --Oneline
D086FF9 Commit G: Merge Branch 'Feature'
0286690 Commit F: modifié B.SMS
7C5C85E Commit E: modifié un.SMS
2BBDE47 Commit C: Ajouté C.SMS
B430AB5 Commit B: Ajouté B.SMS
6F30E95 COMMISS.SMS
$ ls
un.txt b.txt c.SMS

Résultats pour «fonctionnalité»:

$ GIT CHECKOT FEATTOW
Couché à la «fonctionnalité» de la branche
$ Git Log --Oneline
0286690 Commit F: modifié B.SMS
7C5C85E Commit E: modifié un.SMS
B430AB5 Commit B: Ajouté B.SMS
6F30E95 COMMISS.SMS
$ ls
un.txt b.SMS

Dans la succursale «maître», vous remarquerez qu'il y a un nouveau engagement qui a fusionné les modifications de la succursale «fonctionnalité». Fondamentalement, les mesures suivantes ont eu lieu:

A - b - c - g (maître)
\ /
E - F (fonctionnalité)

Dans le commit G, toutes les modifications de la succursale «fonctionnalité» ont été introduites dans la branche principale. Mais la succursale «fonctionnalité» elle est restée intacte en raison du processus de fusion. Remarquez le hachage de chaque engagement. Après la fusion, le commit E (7C5C85E) et F (0286690) a le même hachage sur la branche «fonctionnalité» et «maître».

---

3. Fusion avec rebasing

Répétons l'étape 1 pour réaliser à nouveau les branches «maître» et «fonctionnalité».

Résultats pour «maître»:

$ maître de paiement
Changé de succursale «maître»
$ Git Log --Oneline
7F573D8 Commit C: Ajouté C.SMS
795da3c Commit B: ajouté b.SMS
0f4ed5b Commit A: Ajouter un.SMS
$ ls
un.txt b.txt c.SMS

Résultats pour «fonctionnalité»:

$ GIT CHECKOT FEATTOW
Couché à la «fonctionnalité» de la branche
$ Git Log --Oneline
8ed0c4e commit f: modifié b.SMS
6E12B57 Commit E: modifié un.SMS
795da3c Commit B: ajouté b.SMS
0f4ed5b Commit A: Ajouter un.SMS
$ ls
un.txt b.SMS

Rebase à partir de la succursale «fonctionnalité».

$ GIT CHECKOT FEATTOW
Couché à la «fonctionnalité» de la branche
$ Git Rebase Master
Tout d'abord, rembobinant la tête pour rejouer votre travail au-dessus…
Appliquer: Commissez E: modifié un.SMS
Appliquer: Commit F: modifié B.SMS

Puis fusionner la «fonctionnalité» dans «maître».

$ maître de paiement
Changé de succursale «maître»
$ git fusiter la fonctionnalité
Mise à jour de 7f573d8… 9efa1a3
Avance rapide
un.txt | 1 +
b.txt | 1 +
2 fichiers modifiés, 2 insertions (+)

Résultats pour la branche «maître»:

$ maître de paiement
Déjà sur 'Master'
$ Git Log --Oneline
9efa1a3 commit f: modifié b.SMS
8710174 Commit E: modifié un.SMS
7F573D8 Commit C: Ajouté C.SMS
795da3c Commit B: ajouté b.SMS
0f4ed5b Commit A: Ajouter un.SMS
$ ls
un.txt b.txt c.SMS

Résultats de la branche «fonctionnalité»:

$ GIT CHECKOT FEATTOW
Couché à la «fonctionnalité» de la branche
$ Git Log --Oneline
9efa1a3 commit f: modifié b.SMS
8710174 Commit E: modifié un.SMS
7F573D8 Commit C: Ajouté C.SMS
795da3c Commit B: ajouté b.SMS
0f4ed5b Commit A: Ajouter un.SMS
$ ls
un.txt b.txt c.SMS

Notez qu'après la rébase 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 Rebase, c'est ce qui s'est produit:

A - B - C
\
E '- f' (fonctionnalité, maître)

C'est pourquoi il n'y a pas de nouvel engagement. Les commits E et F ont été recalculés et verrouillés à la fin de la branche «maître».

Rebasing est un outil utile lorsque vous souhaitez nettoyer l'histoire de votre travail. Cependant, il y a un danger qui a donné naissance à la règle d'or.

---

Règle d'or de la rebasing

La règle d'or de la rebasing est:

Ne jamais réprimander une branche publique.

Comme vous pouvez le voir dans l'exemple ci-dessus, la rebasing recalcule les commits. Lorsque plusieurs personnes se ramifient à partir d'un référentiel public, Rebasing peut créer des situations où les développeurs qui ont créé de nouvelles succursales se heurteront à des situations de fusion très compliquées. Donc, c'est une bonne idée de ne jamais réprimander les branches publiques qui sont partagées.

En conclusion:

Rebasing est une caractéristique unique de Git. Mais utilisez-le avec prudence.

Plus d'information:

Voici quelques liens pour une étude plus approfondie:

• Documentation Git Rebase
• Atlassian fusionnant vs rebasing
• Comment voir l'historique des engagements du référentiel Git
• Montrez un arbre git dans le terminal
• https: // www.atlassien.com / git / tutoriels / fusion-vs-rebasage
• https: // git-scm.com / docs / git-rebase