3

プルリクエストと組み合わせたレビューを git で確実かつ安全にするツールはありますか?

関連する質問がいくつかあり、それらは github で既に尋ねられています (参照: Using git for Code Reviews、Online Code Review Tool with Git Integration )。

人々はgerritまたはgistの使用を提案してきました。

前の質問で提示された解決策は優れたインターフェイスを備えていますが、アクセス制御に関してはひどく失敗しています。私たちの会社は小さすぎて、コードのレビューを 1 人に強制したり、専任のメンテナーを置いたりすることはできません。したがって、コードが中央レポジトリにプッシュされる前にコードがレビューされるようにする (または少なくとも推奨する) ツールを探しています。

注: 私たちは一般的に従業員を信頼しているため、絶対的なユーザー アクセス制御は必要ありません。ただし、プッシュ権限を 1 人に制限することなく、中央リポジトリへの直接プッシュを禁止したいと考えています。

したがって、ツール (またはツールとスクリプトの組み合わせ) は、少なくとも次のタスクを実行する必要があります。

  • プル リクエストを Web インターフェイスで表示できるようにします。（ゲリットはそれを達成します）
  • 中央リポジトリはそのツールにリンクされているため、読み取り専用アクセスが可能ですが、プッシュを行うには少なくとも別の人が変更セットを確認して承認する必要があります。
  • レビューと承認の責任者は、開発チームの任意の人物にすることができます。
  • ツールは、マージの競合につながるプル リクエストを自律的に検出 (および拒否) する必要があります。
  • コミットの SHA1 ハッシュを変更することが知られている git 関数を使用しないでください。

このソリューションに対する私の提案:

  • プルリクエストとレビューの処理には gerrit を使用します。
  • gerrit には常にマスターのクローンが必要です。
  • プルリクエストごとに、gerrit は、パッチがコンフリクトなしで master に適用可能かどうかをチェックします (これはスクリプト フックであり、gerrit がそれらを備えているかどうかはわかりません)。
  • 中央リポジトリは、シェル アクセス権を持つ特権ユーザー (ここでは という名前gerrit) によって所有され、http(s) 経由で公開されます。
  • 別の人がコードをレビューするたびに、Web インターフェイスに適用ボタンがあり、変更が中央リポジトリに自動的にプッシュされます。

残念ながら、私は gerrit を知りませんし、ドキュメントも不足しています。このワークフローを gerrit で実装することは可能ですか? これらの要件を満たす別のツールはありますか?

4

3 に答える 3

1

厳密には、Gerrit はリポジトリ ホストとして機能できるため、ホスティング用に変更を別のリポジトリにプッシュする必要はありません (ただし、プッシュを許可する組み込みのフックがあります)。

早送りするパッチのみを適用するように Gerrit を制限し、マージが必要なものを拒否することができます。プロジェクトに取り組んでいる人が数人以上いる場合、これはあなたの作業を遅くするかもしれません: コミットする人が多ければ多いほど、受け入れられる前にパッチをリベースしなければならない可能性が高くなります.

パッチの適用は 1 回のクリック操作ではありません。パッチをレビューした後、レビュアーは最初にスコア (-2 から +2 の範囲) を選択し、+2 で [今すぐ適用] ボタンを有効にする必要があります。パッチを検証する CI システムがない場合は、ソースの動作を検証したことを示す必要がある場合もあります。CI ボットがあり、レビュー担当者がコードを見るまでに完了していない場合、レビュー担当者はフィードバックを残すことができ、CI ボットが完了したときに誰でも (権限に応じて) マージをトリガーできます。

「変更を提出したメンバーではない任意のチームメンバー」を意味しない限り、任意のチームメンバーの要件は満たされます。それがあなたが実際に望んでいることだと思いますが、これをさかのぼって取り締まるかもしれません。

于 2012-07-20T16:57:59.980 に答える
1

Gerrit は、ほとんど/すべてのニーズを満たすと思います。Gerrit とやり取りできる Jenkins などの CI ツールを統合し、必要に応じて機能を追加できます。

覚えておくべき 1 つのこと - プル リクエストが作成されたときにパッチが正常にマージされる可能性がありますが、後でマージの競合が発生する可能性があります。開発者 A が問題なくマージできるプル リクエスト 1 を作成し、開発者 B が問題なくマージできるプル リクエスト 2 ～ 9 を作成した場合、2 ～ 9 が最初にレビューされて送信された場合、プル リクエスト 1 は問題なくマージされない可能性があります。

Gerrit には、これを試して検出し、パッチのリベースが必要なときにユーザーに警告する機能があります。

于 2012-07-11T15:38:52.680 に答える