web-dev-qa-db-ja.com

GitHubプルリクエストでピアレビューを行う方法

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

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

可能な場合はサードパーティのコードレビューツールを避け、何らかの回避策を講じてVanilla GitHubを使い続けたいと思います。

12
Borek Bernard

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

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

これが私が通常それを行ったことを見た方法です:

著者を同僚をレビュー担当者として追加する:

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

オープンソースプロジェクトは大まかな階層を持っているようです。おそらく、「コア」コントリビューターがOKを与えた後にのみ、それらの規約はマージすることになるでしょう。

私が現在雇用されているショップでは、チームの半ダースの開発者のいずれかが承認した後、私たちは合併します。

まれに、チームの誰かがコメントを使用して、マージする前にコードをピアレビューする必要があると他の開発者に明確に呼びかける場合がありますが、それ以外の場合は、最初にそこに到達し、そうしたいと思っている人なら誰でもレビューしてコメントを書くことができます。

レビュー担当者の承認:

通常、承認はプルリクエストに「+1」または「lgtm」(私には良さそうに見えます)とコメントすることで示されます。

軽量タスク:

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

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

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

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

6
TehShrike