Collaborer avec issues et pull requests

1. De la demande au changement vérifiable

Une issue décrit un problème, une amélioration ou un travail à organiser. Pour le portail NKILItech, « Ajouter le contact » doit préciser les informations attendues, le comportement du lien et les critères de validation. Une capture ou un exemple aide à comprendre le besoin ; une simple phrase « ça ne marche pas » aide peu.

Une pull request propose d’intégrer les changements d’une branche vers une branche de base. Elle rassemble le contexte et les discussions nécessaires à la revue. La créer ne signifie pas que les modifications sont déjà fusionnées.

2. Préparer une proposition ciblée

git switch main
git pull --ff-only
git switch -c feature/contact-client
Set-Content -Encoding utf8 contact-client.html "<h1>Demander un accompagnement NKILItech</h1>"
git add contact-client.html
git diff --cached
git commit -m "Ajouter le point de contact client"
git push -u origin feature/contact-client

Sur GitHub, choisissez main comme branche de base et feature/contact-client comme branche source. Relisez le diff avant de demander la revue. Une pull request en brouillon est utile pour présenter un travail encore en cours ; elle doit être rendue prête lorsque l’auteur attend une décision de fusion.

Une description utile explique le problème, le résultat obtenu et la manière de vérifier. Exemple : « Les visiteurs ne disposent pas d’une page de contact dédiée. Cette modification ajoute une page présentant le point d’entrée. Vérification : ouvrir la page et contrôler le texte et le lien depuis l’accueil. »

3. Relire et traiter les commentaires

Une revue examine le comportement, la lisibilité et les effets sur les autres usages. Elle ne se limite pas à préférer une indentation. Le relecteur peut demander une correction précise, proposer une amélioration ou approuver selon son rôle.

Pour répondre à un commentaire, modifiez la même branche, créez un commit puis envoyez-le. La pull request est actualisée à partir de cette branche ; il n’est pas nécessaire d’en créer une nouvelle pour chaque correction.

Un contrôle automatisé réussi apporte une preuve sur ce qu’il exécute. Il ne prouve pas à lui seul que le besoin a été compris. Inversement, un contrôle échoué doit être lu : le problème peut concerner le code, la configuration ou un service indisponible.

4. Fusionner et retrouver l’état local

Une fusion classique conserve les relations d’historique des commits. Une fusion squash crée un nouveau commit regroupant le changement sur la cible. Une option rebase and merge rejoue les commits selon le mécanisme proposé par GitHub. Choisissez la stratégie prévue pour le dépôt et comprenez l’effet sur les identifiants et l’ascendance.

Après la fusion sur GitHub, votre main local doit encore être actualisé. Revenez sur main, récupérez les changements puis vérifiez le graphe.

git switch main
git pull --ff-only
git log --oneline --graph --decorate --all

Vous pouvez ensuite nettoyer la branche locale. Une branche fusionnée par squash peut demander une vérification supplémentaire avant suppression, car Git ne reconnaît pas la même intégration par ascendance. La suppression de la branche distante et celle de la branche locale restent deux actions distinctes.

5. Fork, clone et upstream

Un fork est un dépôt hébergé relié à un autre dépôt sur la plateforme. Un clone est une copie de travail locale. Pour contribuer sans droit d’écriture sur le dépôt source, on peut créer un fork, cloner son fork puis proposer une pull request vers le projet d’origine.

git remote -v
git remote add upstream https://github.com/COMPTE_SOURCE/DEPOT_SOURCE.git
git fetch upstream

Remplacez les valeurs de cet exemple par le projet auquel vous êtes autorisé à contribuer. upstream est ici un nom de remote choisi pour le dépôt source. Le mot « upstream » peut aussi désigner la branche suivie par une branche locale : ces deux usages ne sont pas exactement la même configuration.

Pour actualiser main depuis le projet source dans un parcours sans divergence locale : git switch main, puis git merge --ff-only upstream/main après fetch. Les contributions se développent sur une branche séparée.

6. Conventions d’équipe chez NKILItech

Une convention simple peut demander une branche par objectif, une description lisible, au moins une relecture et des vérifications avant intégration. Les protections de branches ou les rulesets permettent d’imposer certaines exigences selon les possibilités du dépôt et de l’offre utilisée.

On peut aussi prévoir un modèle d’issue, un modèle de pull request et une documentation de contribution. Ces documents rendent explicites les attentes : comment reproduire un problème, quels tests exécuter et comment nommer les fichiers.

Une issue fermée ne garantit pas qu’une livraison a eu lieu. Distinguez le travail fusionné, la version préparée et le système effectivement déployé. Cette distinction évite d’annoncer à un client une fonctionnalité encore absente de son environnement.

Exercices corrigés