Fixer les règles de fusion et d’historique

Quand plusieurs personnes contribuent au dépôt du site devenu produit, l’intégration peut ajouter des commits de fusion difficiles à lire ou permettre une modification directe de la branche principale. Vous allez fixer une règle qui rend les changements traçables et limite les intégrations non vérifiées. La stratégie de branches courtes retenue dans la leçon précédente reste le cadre ; ici, vous définissez comment les changements rejoignent la branche principale.

Choisir une intégration sans commit de fusion

Un historique linéaire présente les commits dans une seule succession, sans commits de fusion qui réunissent deux lignes de développement. Pour ce dépôt, adoptez la règle suivante : la branche principale n’est jamais modifiée directement ; chaque proposition est vérifiée, puis intégrée sans commit de fusion. Cette règle facilite la lecture chronologique, mais ne remplace ni la revue ni les contrôles avant intégration.

Une fusion par avance rapide est possible lorsque la branche cible est un ancêtre de la branche à intégrer : Git peut alors déplacer son pointeur vers le nouveau commit, sans créer de commit de fusion. Si les deux branches ont avancé séparément, cette opération n’est pas possible tant que la branche de travail n’a pas été remise à jour. Rebaser cette branche sur la version récente de la branche principale replace ses commits au-dessus de celle-ci ; après résolution éventuelle des conflits, une avance rapide peut rétablir la succession linéaire.

git switch feature/navigation
 git fetch origin
 git rebase origin/main
 git push --force-with-lease origin feature/navigation
 # Après revue et contrôles réussis, depuis une copie à jour de main :
 git switch main
 git pull --ff-only origin main
 git merge --ff-only feature/navigation
 git push origin main

Si la branche principale n’a pas avancé depuis le rebase, git merge --ff-only déplace main au commit de la branche de travail, sans créer de commit de fusion. Si l’avance rapide est impossible, Git refuse l’opération ; arrêtez-vous et mettez à jour la branche de travail avant de réessayer.

Appliquer la règle sur la branche principale

Les commandes locales réduisent les erreurs, mais elles ne suffisent pas à protéger une branche partagée : une autre personne pourrait pousser directement, ou une interface pourrait proposer un mode de fusion différent. Configurez donc la protection de main dans l’hébergeur du dépôt. Les libellés varient selon la plateforme ; cherchez les règles de protection de branche et vérifiez leur effet avec une proposition de test.

• Interdire les mises à jour directes et exiger le passage par une proposition de fusion.
• Exiger la réussite des contrôles définis pour le dépôt ; leur contenu sera détaillé dans la partie consacrée aux contrôles avant fusion.
• N’autoriser que le mode d’intégration compatible avec l’historique linéaire, et désactiver les modes qui créent des commits de fusion.
• Bloquer les mises à jour forcées de main et limiter les possibilités de contourner la règle aux personnes qui administrent le dépôt.

La revue de la proposition permet de vérifier que le changement est compréhensible et conforme au périmètre annoncé. Définissez avec l’équipe qui doit approuver les changements et si certaines modifications sensibles nécessitent une personne compétente sur le sujet. Ne confondez pas une approbation avec un contrôle automatique : la règle de protection doit traiter les deux comme des conditions distinctes si vous les rendez obligatoires.

Vérifier que l’historique reste linéaire

Avant l’intégration, mettez à jour la branche de travail avec la branche principale distante, relancez les vérifications concernées et attendez les approbations prévues. Si main a avancé entre-temps, recommencez la mise à jour et les contrôles : une vérification portant sur un ancien état ne prouve pas que le nouvel état est correct. Après intégration, examinez l’historique pour détecter un mode de fusion qui aurait contourné la convention.

git fetch origin
 git log --graph --oneline --decorate origin/main -n 12

La sortie affiche les derniers commits de main sous forme de graphe. Une succession simple sans embranchements réunis par un commit de fusion est conforme à la règle ; si un commit de fusion apparaît, examinez les paramètres de la protection et le mode d’intégration utilisé.

À retenir

• Rebasez la branche de travail sur la branche principale à jour avant l’intégration.
• Utilisez une avance rapide pour intégrer sans créer de commit de fusion.
• Protégez main contre les mises à jour directes et forcées.
• Exigez les contrôles et la revue prévus, puis vérifiez l’historique obtenu.

Dans la prochaine leçon, vous consignerez les règles retenues dans les fichiers de conventions du dépôt.