Demande de fusion et revue
La demande de fusion (pull request, merge request) : son cycle de vie, une bonne description, les vérifications automatiques, la relecture du diff, l'approbation et la fusion simple ou écrasée ; ce qu'on cherche en relisant.
- 25 cartes
- 4 thèmes
- Gratuit
Le programme, thème par thème
Le poids de chaque thème suit celui que lui donne l'examen.
- Notions
- Questions
- Ranger et relier
- Mises en situation
Quelques cartes du deck
Demande de fusion : de quoi s'agit-il ?
Voir la réponse
Proposition d'intégrer une branche dans une autre, ouverte sur la plateforme d'hébergement, qui réunit la discussion, les vérifications automatiques et l'approbation.
Ce n'est pas une fonction de Git lui-même mais de la plateforme (GitHub parle de pull request, GitLab de merge request) : elle fait relire et vérifier avant que la branche commune ne change.
Ce diff Python est soumis en relecture. Une fois appliqué, que fait connexion pour un login inconnu, quand trouver renvoie None ?
```diff
@@ -1,5 +1,6 @@
def connexion(login, mot_de_passe):
utilisateur = trouver(login)
- if utilisateur is None:
+ print("debug", login, mot_de_passe)
+ if utilisateur is not None:
return False
- return utilisateur.hash == hacher(mot_de_passe)
+ return utilisateur.mot_de_passe == mot_de_passe`- Elle affiche le mot de passe, puis lève une AttributeError
- Elle affiche le mot de passe, puis renvoie False
- Elle affiche le mot de passe, puis renvoie True
- Elle renvoie False sans rien afficher
Voir la réponse
Elle affiche le mot de passe, puis lève une AttributeError
La condition est inversée : avec None, on ne sort pas, et utilisateur.mot_de_passe lève une AttributeError, alors qu'un utilisateur existant reçoit toujours False. Le relecteur doit aussi commenter le print qui expose le mot de passe et la comparaison en clair qui remplace le haché : sécurité et justesse passent avant le style.
Une demande de fusion doit avoir …, avec une description qui dit ce qui change et ….
Voir la réponse
Une demande de fusion doit avoir une seule intention, avec une description qui dit ce qui change et pourquoi.
Le diff montre quoi, jamais pourquoi. Sans la raison, le relecteur ne peut pas juger si le changement répond au besoin.
Relecture de code : de quoi s'agit-il ?
Voir la réponse
Examen d'un changement par une personne autre que son auteur, pour y trouver des défauts et partager la connaissance du code avant qu'il soit intégré.
Elle attrape ce que les tests ne voient pas (lisibilité, sécurité, choix de conception) et fait circuler la connaissance dans l'équipe.
Une demande de 1 800 lignes attend depuis dix jours sans relecture. Quelle est la cause la plus probable ?
- Les relecteurs ne reçoivent aucune notification de la part de la plateforme
- Les vérifications automatiques sont désactivées
- La branche porte un nom qui ne suit pas la convention de l'équipe
- Elle est trop grosse pour être relue
Voir la réponse
Elle est trop grosse pour être relue
Plus un diff est grand, moins on le relit sérieusement, et l'attente s'allonge. La solution : découper en demandes plus petites, une intention par demande, et prévenir les relecteurs avec une description claire.