Nous passons de Bitbucket à GitHub et une chose avec laquelle nous nous débattons sont les revues de code par les pairs qui ont fonctionné très bien sur Bitbucket comme ceci:

1. L'auteur a ouvert une requête Pull (GitHub: le même)
2. L'auteur a ajouté ses collègues en tant que critiques (GitHub: ?? luttant ici avec plusieurs cessionnaires)
3. Relecteur soit:
   1. Approuvé le PR avec une coche verte (GitHub: ??)
   2. Commentaires ajoutés (GitHub: le même)
   3. Tâches légères créées (GitHub: un peu similaire si la - [ ]syntaxe est utilisée dans la description du RP; dommage qu'elle ne fonctionne pas pour les tâches)
4. Il y a une liste de RP où je peux voir en un coup d'œil qui sont examinés et OK pour être fusionnés et qui nécessitent une attention supplémentaire (GitHub: ??)

Je dois souligner que nous voulons éviter les outils de révision de code tiers si possible et que nous souhaitons rester sur GitHub vanilla avec une sorte de solution de contournement.

D'après ce que j'ai vu, la plupart de ces étapes sont effectuées sur Github par convention, et non par un processus officiel fourni par Github.

Mon employeur utilise Github, je gère un bon nombre de petits projets open source et je fais des contributions occasionnelles à d'autres projets open source.

Voici comment je l'ai généralement fait:

Auteur ajoutant ses collègues comme réviseurs:

Cela varie d'un projet à l'autre, mais en général, les pairs examinateurs désignés sont tous des contributeurs au projet .

Les projets open source semblent avoir une hiérarchie approximative - peut-être que leur convention serait de fusionner uniquement après qu'un contributeur «de base» ait donné son accord.

Dans la boutique où je travaille actuellement, nous fusionnons après que l'un des demi-douzaines de développeurs de l'équipe a donné son accord.

En de rares occasions, un membre de l'équipe peut utiliser un commentaire pour appeler spécifiquement un autre développeur qui, selon lui, devrait examiner le code par les pairs avant sa fusion, mais sinon, quiconque y arrive en premier et qui le souhaite peut le réviser et faire des commentaires.

Approbation du réviseur:

L'approbation est généralement montrée en faisant un commentaire sur la demande de tirage en disant "+1" ou "lgtm" (ça me semble bien).

Tâches légères:

J'ai également utilisé les cases à cocher, mais dans la plupart des cas, chaque commentaire sur une demande d'extraction est considéré comme une "tâche" implicite qui est résolue soit par:

• changer le code sur lequel la ligne commente
• répondre avec un autre commentaire

En un coup d'œil, ce qui est approuvé et ce qui doit encore être examiné:

J'ai utilisé l' extension Looks Good To Me pour Chrome, qui vous donne une telle vue à partir de l'écran Pull Requests. La vue de la liste des demandes d'extraction semble avoir été rompue par les récents changements de Github.