BitbucketからGitHubに移行していますが、私たちが苦労しているのは、次のようにBitbucketで非常にスムーズに機能するピアコードレビューです。

1. 著者がプルリクエストを開きました（GitHub：同じ）
2. 著者は同僚をレビュアーとして追加しました（GitHub：?? 複数の譲受人とここで苦労しています）
3. レビュアー：
   1. 緑のチェックマークが付いたPRを承認しました（GitHub：??）
   2. コメントを追加（GitHub：同じ）
   3. 軽量タスクを作成しました（GitHub：- [ ]PRの説明で構文が使用されている場合に似ていますが、タスクでは機能しないことが残念です）
4. 一目で確認できるPRのリストがあり、レビューされていてマージしても問題なく、さらに注意が必要なものがあります（GitHub：??）

可能な限りサードパーティのコードレビューツールを避け、何らかの回避策を備えたバニラGitHubを使い続けたいと思います。

私が見たところ、これらの手順のほとんどは、Githubで提供されている公式のプロセスではなく、慣例によりGithubで実行されます。

私の雇用主はGithubを使用しており、多数の小規模なオープンソースプロジェクトを実行しており、他のオープンソースプロジェクトに時折貢献しています。

これが私が通常どのように行われるのかを示しています。

同僚をレビュアーとして追加する著者：

これはプロジェクトごとに異なりますが、一般に、割り当てられた査読者はすべてプロジェクトへの貢献者です。

オープンソースプロジェクトは大まかな階層を持っているようです-多分彼らの慣習は「コア」貢献者が大丈夫を与えた後にのみマージすることでしょう。

私が現在雇用されている店では、チームの6人の開発者のいずれかが承認した後、合併します。

まれに、チームの誰かがコメントを使用して、マージする前にコードをピアレビューする必要があると考える別の開発者を具体的に呼び出す場合がありますが、そうでない場合は、最初にそこに着いて、そうする気がある人なら誰でもレビューしてコメントを書くことができます。

レビューアの承認：

承認は、通常、プルリクエストに「+1」または「lgtm」とコメントすることによって表示されます（私には良さそうです）。

軽量タスク：

私もチェックボックスを使用しましたが、ほとんどの場合、プルリクエストに対するコメントはすべて、次のいずれかによって解決される暗黙の「タスク」と見なされます。

• 行がコメントしているコードを変更する
• 別のコメントで応答する

何が承認され、何がまだレビューが必要かを一目で確認します。

Chrome のLooks Good To Me拡張機能を使用しました。これにより、プルリクエスト画面からこのようなビューが得られます。ただし、プルリクエストのリストビューは、最近のGithubの変更によって壊れているようです。