Préparer la revue et intégrer le changement

Votre fonctionnalité est prête, mais la branche principale peut avoir changé pendant sa préparation. Avant l’intégration, il faut donc publier le travail, le faire examiner et vérifier qu’il s’accorde avec les changements récents. Vous allez suivre ce parcours avec `feature/nouveaux-guides`, jusqu’à l’intégration de la section « Nouveaux guides ».

Publier le travail et demander la revue

La branche de fonctionnalité et ses commits ont été préparés dans les leçons précédentes. Depuis cette branche, actualisez les références distantes et publiez les commits. La commande de publication utilise ici le suivi déjà configuré ; si vous reprenez le parcours dans un nouveau dépôt où il ne l’est pas, utilisez `git push -u origin feature/nouveaux-guides`, comme dans la leçon sur la publication.

git switch feature/nouveaux-guides
git fetch origin
git push

Dans l’interface de votre hébergeur Git, ouvrez ensuite une demande de fusion de `feature/nouveaux-guides` vers `main`. Résumez le changement — ajout de la section de guides sur la page statique — et indiquez ce que la personne chargée de la revue doit vérifier : contenu, liens de navigation et cohérence de la présentation. N’affirmez pas que la branche est à jour si elle ne l’est pas encore ; la prochaine étape sert précisément à la synchroniser.

Rebaser après l’avancée de la branche principale

Pendant la revue, une autre personne peut faire évoluer `main`. Pour traiter ce cas dans l’exercice, supposez qu’un changement récent de la branche principale touche lui aussi `index.html`, par exemple autour de la zone où la section de guides est ajoutée. Vous ne devez pas écraser ce changement : actualisez `origin/main`, puis rejouez vos commits au-dessus de cette référence. Le rebase peut s’arrêter si les deux modifications ne peuvent pas être combinées automatiquement.

git switch feature/nouveaux-guides
git fetch origin
git rebase origin/main

Si Git signale un conflit, arrêtez-vous avant de publier. Dans cet exercice, le conflit attendu concerne `index.html` : il résulte de changements concurrents apportés au même emplacement, pas d’une erreur dans la demande de fusion. Suivez la méthode de comparaison et de résolution vue dans les leçons précédentes : examinez les deux intentions, puis modifiez le fichier pour conserver à la fois l’évolution de `main` et la section « Nouveaux guides ». Le fichier final doit rester conforme au squelette et au contrat du projet.

git status
# Après édition et contrôle de index.html :
git diff --check
git diff -- index.html
git add index.html
git rebase --continue

Si d’autres commits du rebase entrent eux aussi en conflit, répétez le contrôle, la résolution, git add et git rebase --continue pour chacun.

Après la fin du rebase, contrôlez que l’opération est terminée et que les fichiers ne contiennent plus de marqueurs de conflit. Vérifiez aussi le diff par rapport à `origin/main` : il doit présenter la fonctionnalité attendue, sans supprimer les changements intégrés depuis la branche principale. Si vous ne pouvez pas confirmer que la résolution est correcte, interrompez le rebase avec `git rebase --abort` plutôt que de publier un résultat douteux.

git status
git diff origin/main...HEAD
git push --force-with-lease

Le rebase a réécrit les identifiants des commits de la branche : la publication nécessite donc une mise à jour forcée protégée par `--force-with-lease`. Cette option évite d’écraser silencieusement une mise à jour distante que vous n’auriez pas récupérée. Si la commande est refusée, récupérez les références et vérifiez la situation avant toute nouvelle tentative ; ne remplacez pas cette commande par un push forcé sans protection.

Terminer la revue et intégrer

Retournez sur la demande de fusion après la publication. Vérifiez que son diff correspond bien à la version rebasée, puis répondez aux retours en indiquant les corrections effectuées. La personne chargée de la revue doit pouvoir examiner le résultat après résolution du conflit, et non seulement les changements antérieurs au rebase. Attendez l’approbation requise par votre équipe avant de lancer l’intégration.

Une fois la revue acceptée, faites intégrer la branche selon la méthode choisie par l’équipe dans la leçon consacrée à l’intégration. Si l’intégration est effectuée dans l’interface, utilisez son action de fusion ; ne relancez pas une seconde intégration locale en parallèle. Vérifiez ensuite que la demande est marquée comme intégrée et que `main` contient la fonctionnalité. Vous pourrez marquer cette version livrée avec un tag dans la leçon suivante.

À retenir

• Publiez la branche et ouvrez une demande de fusion vers `main` avec une description vérifiable.
• Rebasez sur `origin/main` si la branche principale a avancé pendant la revue.
• En cas de conflit, préservez l’intention des deux côtés et contrôlez le diff avant de poursuivre.
• Après le rebase, publiez avec `--force-with-lease`, puis faites examiner la version mise à jour.
• Intégrez seulement après la revue, en suivant la procédure de l’équipe.