Un espace de travail de révision de code doit vous aider à relier l'intention proposée, les lignes modifiées, les preuves d'exécution et la décision finale. Il ne doit pas exiger que tous les dépôts et tableaux de bord de l'organisation restent ouverts.
Établir la limite de la révision
Lisez la description de la pull request, le problème associé, la branche de base et le comportement affecté. GitHub recommande de se constituer un contexte avant d'examiner les fichiers modifiés (Files changed). Notez les fichiers présentant le risque le plus élevé et la validation attendue, puis ouvrez le dépôt et la branche correspondants dans l'éditeur.
Placez le diff à côté du code local lorsque la navigation entre les définitions est nécessaire. Gardez la sortie des tests ou de la compilation dans une fenêtre de terminal, et n'ouvrez l'aperçu du produit que lorsque la modification a un comportement visible par l'utilisateur. Ne marquez les fichiers comme révisés qu'après avoir vérifié la version actuelle ; GitHub réinitialise l'état de visualisation lorsqu'un fichier est modifié.
Séparer les preuves de la discussion
Utilisez des commentaires par ligne pour des observations spécifiques, des suggestions pour des modifications exactes et un résumé de révision pour les conclusions transversales. Vérifiez les vérifications (Checks) automatisées de la pull request et inspectez les modifications de dépendances le cas échéant. Une coche verte ne remplace pas la lecture du diff source.
Conclure par une décision de révision
Soumettez un commentaire (Comment), approuvez (Approve) ou demandez des modifications (Request changes) en fonction de la politique de révision du dépôt et des preuves observées. Arrêtez les processus locaux et fermez les fenêtres temporaires par la suite. Wallo peut regrouper le navigateur de diff, l'éditeur, le terminal et les fenêtres d'aperçu, mais il ne connaît ni l'état de la pull request ni la décision de révision.