Comment choisir une stratégie de fusion

Quand utiliser ce guide

Utilise ce guide quand tu veux :

  • Comprendre la différence entre fast-forward, squash et merge commit
  • Choisir la stratégie adaptée à ton projet ou à ta PR
  • Savoir quelles permissions sont requises pour chaque stratégie

Pré-requis

  • Une pull request ouverte sur le dépôt
  • Le niveau d'accès Developer minimum (pour fusionner une PR dont tu es l'auteur) ou Maintainer (pour fusionner les PRs des autres)

Les trois stratégies

Fast-forward (--ff-only)

Ce que ça fait : déplace simplement le pointeur de la branche cible vers le dernier commit de la branche source. Aucun commit de merge n'est créé. L'historique reste parfaitement linéaire.

Avant :   main: A → B
          feat:       B → C → D

Après :   main: A → B → C → D

Quand l'utiliser : - Branches courtes avec peu de commits - Tu veux un historique linéaire lisible avec git log - La branche n'a pas divergé de main (pas de commits sur main pendant que tu travaillais)

Limitation : impossible si la branche cible a avancé depuis la création de la branche source — il faut d'abord rebaser.

Squash

Ce que ça fait : regroupe tous les commits de la branche en un seul commit sur la branche cible. L'historique de la branche est condensé.

Avant :   main: A → B
          feat:       B → C → D → E (3 commits)

Après :   main: A → B → F
          (F = C+D+E fusionnés en un seul commit)

Quand l'utiliser : - Branche avec de nombreux micro-commits de type fix typo, wip, encore un fix - Tu veux que main ne contienne que des commits propres et signifiants - La PR correspond à une seule unité logique de travail

Limitation : les commits individuels sont perdus pour main — difficile de retrouver quel commit précis a introduit un changement avec git bisect.

Merge commit (--no-ff)

Ce que ça fait : crée un commit de merge explicite qui unit les deux branches. L'historique conserve la trace de la branche et de quand elle a été intégrée.

Avant :   main: A → B
          feat:       B → C → D

Après :   main: A → B → C → D → M
                          ↑___↑
                    (M = commit de merge)

Quand l'utiliser : - Branches longues avec historique riche qu'on veut conserver - Tu veux pouvoir git revert l'ensemble de la feature d'un seul coup (revert du commit M) - Les conventions de l'équipe exigent un historique non-rebasé

Limitation : l'historique du projet devient un graphe orienté (DAG) moins lisible avec git log --oneline.

Tableau de comparaison

Critère Fast-forward Squash Merge commit
Historique linéaire ✓ ✓ —
Conserve les commits individuels ✓ — ✓
Commit de merge visible — — ✓
git revert d'une feature entière difficile par commit ✓ (revert M)
git bisect précis ✓ difficile ✓
Idéal pour petites branches propres branches bruyantes features longues

Étapes pour fusionner dans gitrust

Sur la page de la PR (/{owner}/{repo}/pulls/{num}), fais défiler jusqu'à la section Fusion :

  1. Sélectionne la stratégie dans le menu déroulant (Merge commit, Squash, ou Fast-forward)
  2. Si fast-forward est choisi mais impossible (branche divergente), gitrust indique l'erreur — rebaser d'abord
  3. Clique Fusionner la pull request
  4. Confirme si demandé

Sortie attendue : 

Pull request fusionnée avec succès.

Variantes

Fusionner via l'API

curl -X POST \
  -H "Authorization: Bearer gr_pat_xxxx" \
  -H "Content-Type: application/json" \
  -d '{"merge_method": "squash"}' \
  https://gitrust.example.com/api/v1/repos/owner/repo/pulls/1/merge

Valeurs valides pour merge_method : merge, squash, rebase (fast-forward).

Stratégie par défaut de l'équipe

Conventionner une stratégie par dépôt réduit les décisions ad hoc. Les équipes optant pour trunk-based development préfèrent le squash. Les équipes avec des branches longues (GitFlow) préfèrent le merge commit.

Voir aussi