Choisir entre rebase et fusion

Quand plusieurs personnes travaillent sur la même fonctionnalité, intégrer une branche ne consiste pas seulement à faire entrer son code dans la branche principale. Le choix de la commande détermine aussi la forme de l’historique et la façon dont le travail commun reste visible. Vous allez choisir entre rebase et fusion selon le contexte, sans modifier les fichiers du site.

Dans la leçon précédente, vous avez rebasé `feature/nouveaux-guides` sur `origin/main` avant la revue. Ici, vous décidez comment intégrer cette branche une fois la revue approuvée : un historique linéaire favorise la lecture chronologique, tandis qu’une fusion avec commit peut rendre visible le regroupement du travail d’équipe.

Deux stratégies, deux histoires

Avec un rebase, Git rejoue les commits de votre branche au-dessus d’un autre point de départ. Le résultat présente les changements comme une suite de commits linéaire, sans commit de fusion pour matérialiser le croisement des branches. Cette approche convient souvent à une branche de fonctionnalité que vous êtes seul à faire évoluer, avant sa revue ou son intégration, si les conventions de l’équipe le demandent.

Avec une fusion, `git merge` intègre les changements d’une branche dans celle que vous avez sélectionnée. Si la branche cible n’a pas reçu de commit divergent depuis le point où la branche de fonctionnalité en est partie, Git peut simplement avancer son pointeur : c’est une avance rapide, ou *fast-forward*. Aucun commit de fusion n’est alors nécessaire, et l’historique reste linéaire sans rejouer les commits de la fonctionnalité.

Si les deux branches ont avancé séparément, une fusion peut créer un commit de fusion. Celui-ci relie les deux lignes de développement et conserve la trace du moment où le travail de la fonctionnalité a été intégré. Il est utile lorsque l’équipe veut garder cette information, par exemple pour des branches collaboratives ou pour rendre le regroupement des changements explicite dans l’historique.

Intégrer la fonctionnalité Sentiers

Supposons que la demande de fusion de `feature/nouveaux-guides` soit approuvée et que l’équipe privilégie un historique linéaire. Vous travaillez sur `main`, vous mettez à jour ses références distantes, puis vous fusionnez la branche de fonctionnalité. Si `main` est toujours un ancêtre de la branche, Git effectue une avance rapide : la commande intègre le travail sans créer de commit supplémentaire.

git switch main
git fetch origin
git merge --ff-only feature/nouveaux-guides

La branche main avance jusqu’au dernier commit de feature/nouveaux-guides. Aucun commit de fusion n’est créé. Si l’avance rapide est impossible, Git refuse l’opération et laisse les branches inchangées.

L’option `--ff-only` exprime une décision stricte : acceptez l’intégration seulement si elle peut rester linéaire. Si un commit propre à `main` empêche l’avance rapide, ne remplacez pas cette option au hasard. Vérifiez la politique de l’équipe et le graphe des commits, puis choisissez soit de remettre à jour la branche de fonctionnalité selon la procédure convenue, soit d’effectuer une fusion qui conserve les deux lignes de développement.

Si l’équipe souhaite garder un point de fusion explicite, vous pouvez demander à Git de créer un commit de fusion même lorsque l’avance rapide serait possible. Cette option est pertinente seulement si cette trace apporte une information utile et correspond aux règles de l’équipe. Elle produit une histoire différente de l’intégration précédente : le commit de fusion rend visible le regroupement de la fonctionnalité.

git switch main
git fetch origin
git merge --no-ff feature/nouveaux-guides

Git intègre feature/nouveaux-guides à main en créant un commit de fusion, même si une avance rapide était possible. Git peut ouvrir l’éditeur pour le message de ce commit.

Décider selon le partage et la politique

Le critère essentiel pour le rebase est le partage de la branche. Rebaser une branche publiée que d’autres personnes utilisent réécrit ses commits et peut les obliger à réorganiser leur propre travail. Réservez cette réécriture à une branche dont vous maîtrisez l’évolution, ou suivez une procédure d’équipe explicitement coordonnée. Une branche déjà partagée se prête généralement mieux à une fusion qui préserve ses commits existants.

Pour `feature/nouveaux-guides`, le rebase effectué avant la revue a aligné votre travail sur `origin/main` ; il ne détermine pas à lui seul la méthode d’intégration finale. Si la plateforme ou l’équipe impose une fusion avec commit, respectez cette règle après approbation. Si elle exige un historique linéaire, préférez une avance rapide ou le mécanisme de fusion linéaire prévu par la plateforme, plutôt que d’ajouter un commit de fusion inutile.

Après l’intégration, contrôlez l’historique pour vérifier qu’il correspond à la décision prise : une suite linéaire de commits ou un point de fusion identifiable. Les commandes de cette leçon supposent que les modifications de la branche ont déjà été revues et approuvées ; elles ne remplacent pas le contrôle du contenu ni les règles de protection de `main`. Si Git signale un conflit, arrêtez-vous : les leçons suivantes traiteront l’origine et la résolution de cette situation.

À retenir

• Le rebase convient surtout à une branche que vous contrôlez et permet de présenter un historique linéaire.
• La fusion préserve les lignes de développement ; un commit de fusion peut en rendre le regroupement visible.
• Une avance rapide déplace la branche cible sans créer de commit de fusion.
• Choisissez selon le partage de la branche et les conventions de l’équipe ; ne réécrivez pas sans coordination une branche utilisée par d’autres.

Dans la prochaine leçon, vous apprendrez à repérer pourquoi Git ne peut pas intégrer directement deux changements concurrents.