Préparer une demande de fusion exploitable

Une branche publiée ne suffit pas à rendre un changement facile à examiner. Sans description claire, les personnes chargées de la revue doivent deviner ce qui a été ajouté, où le vérifier et quelles vérifications vous avez effectuées. Dans cette leçon, vous préparez une demande de fusion exploitable pour la section « Nouveaux guides » du site Sentiers.

La branche `feature/nouveaux-guides` contient le commit atomique de la fonctionnalité et est publiée sur `origin`. Comme expliqué dans la leçon précédente, cette publication rend vos commits disponibles sur le dépôt distant ; elle n’ouvre pas automatiquement une demande de fusion. Aucun fichier du projet n’est modifié dans cette étape : vous préparez la revue à partir du changement déjà enregistré.

Choisir la bonne cible

Dans l’interface d’hébergement de votre dépôt, créez une demande de fusion depuis `feature/nouveaux-guides` vers la branche principale du projet. Selon la plateforme, cette action peut aussi être nommée demande de fusion ou demande de tirage ; le principe reste le même : proposer l’intégration d’une branche dans une autre pour permettre son examen avant livraison.

La branche que vous proposez d’intégrer est la branche source ; celle qui recevrait le changement est la branche cible. Pour cette fonctionnalité, vérifiez les deux sélecteurs avant de créer la demande : la source doit être `feature/nouveaux-guides` et la cible doit être la branche principale, par exemple `main` si c’est le nom utilisé dans votre dépôt. Une cible inversée proposerait le changement dans le mauvais sens.

Rédiger un titre et une description utiles

Le titre doit nommer le résultat attendu plutôt que décrire une opération Git. Par exemple, « Ajouter la section Nouveaux guides à la page Sentiers » permet de comprendre le changement sans ouvrir la liste des commits. Évitez les titres vagues comme « Modifications » ou « Travail sur le site » : ils ne donnent aucune indication sur le périmètre de la revue.

Dans la description, donnez le contexte nécessaire à la personne qui examine le changement : ce que vous avez ajouté, où le trouver et pourquoi cela répond au besoin. Ici, précisez que la page présente désormais une section « Nouveaux guides », avec trois cartes d’itinéraires, dans `index.html`. Signalez aussi le périmètre : `style.css` est concerné uniquement si la branche contient effectivement des ajustements de présentation. Ne déclarez pas un fichier modifié s’il ne l’est pas.

Ajoutez les vérifications réellement effectuées, sans transformer une intention en résultat. Pour une page statique, vous pouvez indiquer que vous avez ouvert `index.html` dans un navigateur et contrôlé la présence des trois guides, les liens de navigation et l’affichage de la section. Si vous n’avez pas réalisé une vérification, dites-le clairement ou laissez-la en attente ; la revue doit refléter l’état réel du travail.

Utiliser une liste de vérification

Une liste de vérification rend visibles les points à valider et aide à éviter les oublis. Adaptez ses éléments au changement : elle ne doit pas être un formulaire générique qui prétend que des contrôles ont eu lieu. Cochez un point seulement après l’avoir vérifié ; si la plateforme permet d’ajouter des éléments non cochés, utilisez-les pour les contrôles qui restent à faire.

• La section « Nouveaux guides » apparaît sur la page d’accueil.
• Les trois cartes présentent les intitulés et descriptions prévus.
• Les liens de navigation vers les guides et vers la présentation du site sont cohérents.
• Les fichiers modifiés correspondent au périmètre annoncé dans la description.

Créer la demande et vérifier son état

Une fois le titre, la description et la cible vérifiés, créez la demande dans l’interface du dépôt. Vérifiez ensuite qu’elle affiche bien `feature/nouveaux-guides` comme source et la branche principale comme cible. Assurez-vous que la liste des changements présentée correspond à l’ajout de la section et ne contient pas de modification étrangère à la fonctionnalité.

La demande est un espace de préparation et d’examen : sa création n’intègre pas à elle seule la fonctionnalité dans la branche principale. Conservez une description factuelle et mettez-la à jour si le périmètre change pendant la suite du travail. Les retours détaillés de revue et leur traitement seront abordés dans la leçon suivante ; pour l’instant, votre objectif est de fournir un contexte suffisamment précis pour commencer l’examen.

À retenir

• Proposez `feature/nouveaux-guides` vers la branche principale, en vérifiant le sens source-cible.
• Choisissez un titre qui décrit le résultat fonctionnel, puis précisez le contexte et le périmètre dans la description.
• Indiquez uniquement les contrôles réellement effectués et adaptez la liste de vérification au changement.
• La demande de fusion prépare l’examen ; elle ne remplace ni le commit publié ni l’intégration ultérieure.