Contenu du cours
Fondamentaux de GitHub
Fondamentaux de GitHub
Principes de Base du Rebasage
Création d’un commit sur la branche main
Commençons par effectuer un commit directement sur la branche main
distante en modifiant le fichier README.md
dans le dépôt distant. Cela entraînera une divergence de l’historique des commits entre la branche main
et la branche feature/payment
.
Voici la ligne ajoutée au fichier :
Voici le message de commit correspondant :
Comprendre le rebasage
Comme mentionné dans le chapitre précédent, une fois que la branche feature a été relue et testée, elle peut et doit être fusionnée dans la branche main
. Jusqu'à présent, nous avons uniquement utilisé la commande git merge
à cette fin. Cependant, une autre approche consiste à utiliser la commande git rebase
.
Le rebasage est le processus de déplacement ou de combinaison d'une séquence de commits vers un nouveau commit de base. Cela s'effectue en rejouant les modifications d'une branche sur une autre, ce qui aboutit à un historique de commits linéaire.
Lorsque nous créons une branche, Git suit le dernier commit sur les deux branches. Si une seule branche comporte de nouveaux changements, Git peut avancer rapidement et appliquer les modifications. Cependant, si les deux branches ont de nouveaux changements, Git crée un nouveau commit de fusion, ce qui donne lieu à une fusion à trois voies.
Voici à quoi ressemblerait une fusion à trois voies dans notre cas, où C4 était le dernier commit sur la branche feature/payment
avant la fusion :
Cependant, les fusions à trois voies peuvent compliquer le débogage en raison de l’historique divisé et non linéaire. En utilisant le rebasage, nous changeons la base de nos commits et les rejouons sur la nouvelle base, permettant à Git d’effectuer une fusion en avance rapide et de maintenir un historique linéaire.
Voici une animation pour illustrer comment le rebasage peut être effectué dans notre cas (les identifiants de commit ne correspondent pas aux réels ici) :
Lorsque vous rebasez une branche, vous réécrivez essentiellement son historique. Cela signifie que les anciens commits sont remplacés par de nouveaux, qui ont des identifiants différents (somme de hachage) car ils sont basés sur des instantanés différents du code. Comme illustré dans l’animation ci-dessus, l’identifiant du commit sur la branche feature/payment
a changé après le rebasage.
Merci pour vos commentaires !