DevOps Bootcamp · Leçon

Rebasage ou fusion

Comparez le rebasage et la fusion, et apprenez quand utiliser chacun pour conserver un historique propre et linéaire.

Rebasage ou fusion est une leçon DevOps Bootcamp gratuite sur CoddyKit. Ceci est la leçon 3 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage DevOps Bootcamp, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours DevOps Bootcamp comprend 4 leçons au total.

Fusionner ou réappliquer ? Le choix

Lorsque vous travaillez avec Git, il arrive souvent que votre branche diverge d’une autre, par exemple votre branche feature de main.

Comment réunir ces modifications ? Git propose deux stratégies principales : la fusion et la réapplication. Toutes deux permettent l’intégration, mais elles procèdent de façons fondamentalement différentes, ce qui produit des historiques de projet différents.

Fusionner : combiner les historiques

La fusion est la méthode utilisée par défaut par Git pour intégrer les modifications. Lorsque vous fusionnez une branche dans une autre, Git prend le contenu de la branche source et le combine avec celui de la branche cible.

La caractéristique essentielle d’une fusion est qu’elle crée une nouvelle validation de fusion. Cette validation possède deux validations parentes, ce qui montre explicitement que deux historiques divergents ont été réunis. Elle conserve l’historique exact des deux branches.

Effectuer une fusion Git

Examinons une fusion simple. Nous allons créer une branche feature, ajouter une validation, puis la fusionner à nouveau dans main.

git init my_merge_project
cd my_merge_project
echo "Initial content" > file.txt
git add .
git commit -m "Initial commit"

git branch feature
git checkout feature
echo "Feature A" >> feature.txt
git add .
git commit -m "Add feature A"

git checkout main
echo "Main update" >> main.txt
git add .
git commit -m "Update main"

git merge feature

git log --oneline --graph

Fusion : avantages et inconvénients

La fusion est simple et sûre pour les branches partagées, mais elle peut produire un historique « désordonné ».

Avantages :
Conserve l’historique exact des validations.
Non destructive : elle ne réécrit pas les validations existantes.
Simple à utiliser et à comprendre.
Inconvénients :
Peut créer un historique « bruyant » comportant de nombreuses validations de fusion.
Le graphe peut sembler complexe lorsque de nombreuses branches y sont fusionnées.

Réappliquer : réécrire l’historique

La réapplication est une solution différente de la fusion, qui intègre les modifications en déplaçant ou en combinant une suite de validations sur une nouvelle validation de base. Au lieu de créer une validation de fusion, elle réécrit l’historique du projet.

En pratique, les validations de votre branche de fonctionnalités sont « rejouées » au-dessus de la dernière validation de la branche cible, donnant l’impression que vous aviez commencé votre travail à cet endroit. Cela crée un historique linéaire sans validations de fusion supplémentaires.

Effectuer une réapplication Git

Essayons maintenant le même scénario avec une réapplication. Nous allons réappliquer notre branche feature sur main.

Remarquez que la validation de la branche feature est réappliquée au-dessus de la dernière validation de main, puis qu’une fusion à avance rapide fait pointer main vers celle-ci.

git init my_rebase_project
cd my_rebase_project
echo "Initial content" > file.txt
git add .
git commit -m "Initial commit"

git branch feature
git checkout feature
echo "Feature B" >> feature.txt
git add .
git commit -m "Add feature B"

git checkout main
echo "Main update 2" >> main.txt
git add .
git commit -m "Update main 2"

git checkout feature
git rebase main

git checkout main
git merge feature

git log --oneline --graph

Réapplication : avantages et inconvénients

La réapplication crée un historique propre, mais elle s’accompagne d’un avertissement important concernant les branches partagées.

Avantages :
Crée un historique de projet propre et linéaire.
Rend l’historique des validations plus facile à parcourir et à comprendre.
Permet de nettoyer les validations (les regrouper ou les réordonner) avant l’intégration.
Inconvénients :
Réécrit l’historique des validations.
Peut être dangereuse si elle est utilisée sur des validations déjà envoyées vers un dépôt distant partagé (public).

Fusion ou réapplication : comparaison

Voici un résumé rapide des principales différences :

Fusion :
Crée une nouvelle validation de fusion.
Conserve l’historique complet et exact.
Non destructive.
Le graphe peut être complexe.
Réapplication :
Réécrit l’historique, sans validation de fusion.
Produit un historique linéaire.
Destructive (modifie les identifiants des validations).
Le graphe est très clair.

Choisir votre stratégie

Alors, quand utiliser l’une ou l’autre ?

Utilisez la fusion lorsque :
Vous travaillez sur des branches publiques ou partagées (par exemple main, develop).
Vous devez conserver l’historique exact de votre projet.
Vous souhaitez montrer explicitement à quel moment des historiques divergents ont été réunis.
Utilisez la réapplication lorsque :
Vous travaillez sur votre branche de fonctionnalité privée avant de l’envoyer.
Vous souhaitez un historique propre et linéaire.
Vous souhaitez organiser les validations de votre branche de fonctionnalité (par exemple les regrouper ou les réordonner) avant l’intégration.

La règle d’or : ne réappliquez jamais des validations déjà envoyées vers un dépôt distant partagé ! La réapplication d’un historique partagé peut causer de graves difficultés à vos collaborateurs.

Vérification rapide : fusion ou réapplication ?

Examinez les propriétés des deux principales stratégies d’intégration de Git.

Récapitulatif : fusion ou réapplication

Dans cette leçon, nous avons étudié les deux méthodes fondamentales de Git pour intégrer les modifications : la fusion et la réapplication.

La fusion combine les historiques à l’aide d’une nouvelle validation de fusion, tout en conservant toutes les validations d’origine.
La réapplication réécrit l’historique et crée un déroulement linéaire en déplaçant les validations.

Choisissez judicieusement en fonction du flux de travail de votre équipe et souvenez-vous de la règle d’or : ne réappliquez jamais un historique public ! Cette compréhension est essentielle pour préserver un flux de travail Git propre et collaboratif.

Questions Fréquemment Posées

La leçon « Rebasage ou fusion » est-elle gratuite ?

Oui — le texte complet de « Rebasage ou fusion » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours DevOps Bootcamp, passe à CoddyKit PRO. Le cours DevOps Bootcamp comprend 4 leçons au total.

Qu'est-ce que j'apprendrai dans « Rebasage ou fusion » ?

Comparez le rebasage et la fusion, et apprenez quand utiliser chacun pour conserver un historique propre et linéaire. Tu pratiques DevOps Bootcamp avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.

Dois-je avoir de l'expérience pour commencer DevOps Bootcamp ?

Aucune expérience préalable n'est requise. DevOps Bootcamp sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 3 sur 4.

Combien de temps prend la leçon « Rebasage ou fusion » ?

La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.

Peux-tu écrire et exécuter du code dans cette leçon DevOps Bootcamp ?

Oui. Chaque leçon DevOps Bootcamp inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.

Toutes les leçons de ce cours

← Retour à DevOps Bootcamp