Faire relire un changement avant de le publier
Une pull request (demande de fusion) est une proposition de changement : vous demandez à l’équipe de relire une branche avant de la fusionner dans main. Elle permet de repérer une erreur avant qu’elle arrive dans la version que tout le monde utilise.
Une association de quartier garde ses horaires dans un dépôt Git. Avant de publier de nouveaux horaires, une personne relit le changement et dit oui ou non.
À la fin de cette leçon
Remarque
Je peux proposer un changement et en relire un.
Mots-clés
| Mot | Ce que ça veut dire |
|---|---|
| Pull request | une demande de fusion d’une branche, avec une discussion |
| Relecture | la lecture d’un changement par une autre personne |
| Diff | la liste des lignes ajoutées et retirées |
| Commentaire | une remarque attachée à une ligne du diff |
| Approbation | l’accord de la personne qui a relu |
| Petit changement | un changement qu’on relit en quelques minutes |
Les cellules que les étudiants remplissent restent vides dans cet aperçu.
Une pull request propose une branche
On ne pousse pas ses changements directement sur main. On travaille sur une branche, on la pousse sur le serveur, puis on ouvre une pull request.
Elle montre le diff, c’est-à-dire les lignes ajoutées et retirées, et ouvre une discussion. Quand la relecture est bonne, la branche est fusionnée dans main.
Un mot de passe dans une adresse
Attention
L’adresse de clone ci-dessous contient le compte et le mot de passe du labo, pour que Git ne pose aucune question. C’est acceptable sur un serveur d’essai que vous seul atteignez. N’écrivez jamais un vrai mot de passe dans une adresse : utilisez un jeton, que le serveur peut retirer.
Cloner hello-git dans le dossier proposition
git clone http://student:student@gitea:3000/student/hello-git.git propositionAffichée ici, non exécutée. Créez un compte gratuit pour appuyer sur Exécuter et la saisir dans le terminal de votre propre labo.
Créer la branche ajouter-horaires
git -C proposition switch -c ajouter-horairesAffichée ici, non exécutée. Créez un compte gratuit pour appuyer sur Exécuter et la saisir dans le terminal de votre propre labo.
Écrire les horaires dans un nouveau fichier
printf 'Lundi 9h-12h\nMercredi 14h-17h\n' > proposition/horaires.txtAffichée ici, non exécutée. Créez un compte gratuit pour appuyer sur Exécuter et la saisir dans le terminal de votre propre labo.
Choisir le fichier pour le commit
git -C proposition add horaires.txtAffichée ici, non exécutée. Créez un compte gratuit pour appuyer sur Exécuter et la saisir dans le terminal de votre propre labo.
Enregistrer le changement
git -C proposition commit -m "Ajouter les horaires"Affichée ici, non exécutée. Créez un compte gratuit pour appuyer sur Exécuter et la saisir dans le terminal de votre propre labo.
Pousser la branche vers Gitea
git -C proposition push -u origin ajouter-horairesAffichée ici, non exécutée. Créez un compte gratuit pour appuyer sur Exécuter et la saisir dans le terminal de votre propre labo.
Ouvrir la pull request dans Gitea
Ouvrez Gitea dans votre navigateur et connectez-vous avec le compte student, mot de passe student. Ouvrez le dépôt hello-git, choisissez la branche ajouter-horaires et demandez une pull request vers main.
Écrivez un titre clair et une description. Gitea montre le diff. Lisez-le, écrivez un commentaire sur une ligne, puis fermez la pull request sans la fusionner : main reste intact pour le travail noté du labo.
Que regarde une relecture ?
Le relecteur lit le diff avec quelques questions. Le titre dit-il ce qui change ? La description dit-elle pourquoi ? Le changement est-il assez petit pour être relu ? Les tests suivent-ils le code ? Y a-t-il un secret, comme un mot de passe ?
Un bon commentaire est précis et poli. Il dit quoi, pourquoi, et propose une piste.
Exemple travaillé : cinq règles de relecture
| Règle | Pourquoi | Limite de l’exercice |
|---|---|---|
| Titre clair | On le lit dans la liste des changements | Non vide, 60 signes au plus |
| Description | Elle dit pourquoi on change | Non vide |
| Petit changement | On relit mal un très long diff | 300 lignes au plus |
| Tests avec le code | Un code changé sans test n’a aucune preuve | Un fichier de tests si un fichier de src/ change |
| Aucun secret | Un mot de passe poussé est à changer partout | Ni fichier .env ni fichier .key |
Les cellules que les étudiants remplissent restent vides dans cet aperçu.
Une erreur fréquente
Attention
On croit souvent qu’une relecture sert à trouver un coupable ou à refaire le travail de l’auteur. Ce n’est pas vrai : on relit le changement, pas la personne. Un bon relecteur pose des questions, nomme le problème et propose une piste.