Valider le flux complet avant fusion

Une modification peut sembler terminée tout en échouant à un contrôle, en reposant sur une branche mal mise à jour ou en exposant un secret. Avant de fusionner, vous devez donc vérifier le parcours complet : état local, historique, contrôles automatiques, revue et règles de branche.

Dans le projet fil rouge, ce parcours concerne les changements apportés au dépôt du site devenu produit. La stratégie, les rôles et les protections ont déjà été définis ; cette leçon vous fait les appliquer comme une procédure de validation, sans modifier les fichiers du site.

1. Partir d’un état de travail vérifiable

Commencez par vous placer sur la branche de la proposition à valider et examinez l’état du dépôt. Dans le scénario précédent, la branche de travail est feature/guide-recuperation ; la branche recuperation/guide-local est une sauvegarde de récupération, pas la branche à fusionner. Vérifiez que vous n’avez ni fichier modifié ni fichier non suivi que vous risqueriez de confondre avec le changement proposé.

git status --short --branch
git switch feature/guide-recuperation
git status --short --branch
git fetch origin
git log --oneline --decorate -5

La première commande affiche la branche courante et les changements locaux. Après le changement de branche, vérifiez que vous êtes bien sur feature/guide-recuperation et que l’arbre de travail est propre. git fetch origin met à jour les références distantes sans modifier vos fichiers ; le journal permet de contrôler les commits récents.

Si l’arbre de travail n’est pas propre, arrêtez-vous et identifiez chaque changement avant de continuer. Ne supprimez pas des fichiers non suivis simplement pour obtenir un état propre : ils peuvent contenir du travail utile. Si vous devez mettre du travail de côté, appliquez la procédure de sauvegarde vue dans la leçon sur la réparation des incidents, puis reprenez seulement lorsque son contenu est compris.

2. Mettre à jour et examiner la proposition

Comparez la branche de travail à la branche principale distante. Si les commits de origin/main ont avancé, mettez à jour votre branche par rebase, puis résolvez et vérifiez les éventuels conflits sur cette branche. Cette étape suit la règle d’historique linéaire déjà définie ; ne réécrivez pas les commits de la branche principale publiée.

git rebase origin/main
git status --short --branch
git diff --check origin/main...HEAD
git diff --stat origin/main...HEAD
git diff origin/main...HEAD

Le rebase actualise la branche de travail par rapport à origin/main. git diff --check signale notamment les espaces problématiques ; --stat résume les fichiers concernés et le dernier diff permet de vérifier le contenu exact. Si le rebase s’interrompt sur un conflit, réglez-le avant de poursuivre et contrôlez à nouveau le diff.

Examinez ensuite le diff comme une proposition destinée à l’équipe : chaque modification doit correspondre à l’objectif annoncé, et aucun fichier local sensible ne doit apparaître parmi les changements. Les contrôles de secrets vus précédemment sont préventifs, mais leurs résultats ne remplacent pas la lecture du diff. Si un identifiant secret a été ajouté, ne le recopiez pas dans la proposition ni dans le compte rendu ; traitez-le comme compromis et suivez la procédure de révocation ou de rotation.

3. Lire les contrôles et appliquer les règles de fusion

Ouvrez ensuite la proposition de fusion dans le service d’équipe. Confirmez qu’elle cible la branche principale, que son résumé décrit le changement, que les contrôles requis ont fini avec succès et qu’une personne habilitée a approuvé la revue. Un contrôle encore en cours n’est pas un contrôle réussi ; un échec doit être analysé et corrigé, puis les vérifications doivent être relancées.

Pour le site statique, vérifiez que les contrôles configurés couvrent les liens internes et la possibilité de générer ou servir le site avec ses fichiers. Lisez le rapport du pipeline et reliez chaque statut à son étape : un statut global vert doit correspondre à l’exécution effective des contrôles attendus, pas à l’absence de pipeline. Si la branche a changé après une approbation ou après les contrôles, vérifiez que le service a bien recalculé les statuts et les approbations selon les règles configurées.

4. Consigner la décision et clôturer le parcours

Avant la fusion, consignez dans la proposition ou dans le suivi d’équipe le périmètre du changement, les contrôles exécutés, leurs résultats, la revue obtenue et les éventuels incidents rencontrés. Cette trace aide l’équipe à comprendre pourquoi le changement a été accepté et fournit des éléments utiles si une régression apparaît ensuite. Elle ne remplace ni les tests ni les protections automatiques.

• Vérifiez la branche, l’état local et le diff avant de soumettre ou de mettre à jour une proposition.
• Rebasez la branche de travail sur la branche principale à jour et contrôlez l’historique et les changements obtenus.
• N’acceptez que les statuts requis réussis, une revue valide et l’absence de secret dans les changements.
• Respectez les protections ; consignez la décision, les résultats et les incidents pour rendre le parcours vérifiable.

Après la fusion, surveillez les contrôles et le comportement du site selon les pratiques de livraison de votre équipe, puis consignez toute anomalie et sa résolution.