Fusionne en fast-forward ou avec un merge commit

01Observe le scénario fast-forward

cd /tmp/soria-git-branches-$USER/fast-forward
git log --oneline --decorate --graph --all
git merge-base main feature/healthcheck
git rev-list --count main..feature/healthcheck

main est encore l’ancêtre direct de la branche fonctionnalité.

02Exige le fast-forward

git switch main
git merge --ff-only feature/healthcheck
git rev-parse main
git rev-parse feature/healthcheck
git show -s --format='%H%nparents=%P%n%s' HEAD

Les deux références pointent vers le même commit. HEAD possède un seul parent : aucun merge commit n’a été créé.

03Observe un historique divergent

cd ../merge-commit
git log --oneline --decorate --graph --all
git log --left-right --oneline main...feature/backup

La branche feature contient le runbook tandis que main contient une modification d’exploitation. Aucun côté n’est l’ancêtre direct de l’autre.

04Crée un merge commit explicite

git switch main
git merge --no-ff feature/backup -m "merge: integrate backup runbook"
git show -s --format='%H%nparents=%P%n%s' HEAD
git log --oneline --decorate --graph --all

Le commit final possède deux parents : l’ancien HEAD de main et le dernier commit de la branche intégrée.

05Vérifie le contenu, pas seulement le graphe

test -f docs/backup.md
test -f operations.conf
git diff HEAD^1 HEAD --stat
git diff HEAD^2 HEAD --stat
git status --porcelain

06Teste les politiques

git merge --ff-only feature/backup
# échoue si la fusion nécessite un merge commit

git merge --no-ff feature/backup
# conserve une frontière de branche même si un fast-forward serait possible

Une équipe peut choisir une politique uniforme. L’important est que le graphe corresponde au besoin de traçabilité, et non à une option utilisée par habitude.

07Évite de confondre contenu et forme

Deux historiques peuvent produire le même état final des fichiers tout en conservant une structure différente. La recette doit donc vérifier à la fois contenu, tests et forme du graphe attendue.