web-dev-qa-db-ja.com

BitBucketでgitプルリクエストを使用した2レベルのコードレビュー

次の手順：開発ブランチと

  1. 開発者が開発から機能ブランチを作成
  2. このブランチで作業してコミットする
  3. 開発からのリベース
  4. プルリクエストを作成する
  5. コードレビュー
  6. 開発とマージ

別の人が実行する2レベルのコードレビューが必要な問題。 1回目のレビューの承認後、2回目のレビューが行われ、その後マージされます。

これを行う方法？機能ブランチと開発ブランチの間に追加のブランチを追加する必要がありますか？またはもっと簡単な方法は？

gitcode-reviewspull-requestsbitbucket
3
Alexan

他のチームが所有するマイクロサービスや、テックパブへのドキュメントの変更のために、私はこれをかなり頻繁に行っています。マイクロサービスごとに個別のリポジトリがあり、1つまたは2つのスクラムチームのみがそれぞれのマージ権限を持っています。自分のチームの時間を無駄にする前に、自分のチームに徹底的に見直してもらいたい。

私が見つけた最も簡単な方法は、レポジトリをプライベートプロファイルにフォークし、フォークのブランチからすべての作業を行うことです。私は最初に私のフォークでmasterに対してプルリクエストを行い、それが承認されたら、「公式」リポジトリでmasterに対してプルリクエストを行います。

私がこのようにして始めた理由は、私たちのチームがある程度信頼できるイノベーターであるためです。他のチームは、質問せずに送信したものをマージするだけです。別のリポジトリで最初のプルリクエストを行うと、ボタンをクリックするだけでは時期尚早にそれをマージできなくなります。両方のリポジトリの権限と可視性は簡単に制御されます。

個人のフォークでこれを行う必要はありません。ユースケースで機能する場合は、より長寿命の大きなグループのリポジトリを作成できます。たとえば、特定の請負会社からのすべての1つのレポ。

3
Karl Bielefeldt

これを処理する方法は2つあります。

  1. 最初のリクエストが成功した後に2番目のプルリクエストを設定します。最初のPRを完了してマージしないようにしてください。ここでの欠点は、ブランチが誤ってマージされる可能性があることです。

  2. 両方のユーザー（またはグループ）をプルリクエストに追加し、完了する前に両方にサインオフするように要求します。両方がサインオフしたら、それをマージします。最初のユーザーがサインオフする前に2人目のユーザーがPRの通知を受け取るため、「準備ができていない」PRを探している可能性があります。 PRが通常拒否されるか、多くの変更が必要な場合、それは問題である可能性がありますが、それ以外の場合は問題になりません。

2番目のオプションは、両方のPRが完了する前にブランチが誤ってマージされる可能性がないため、私にとって最も理にかなっています。

5
mmathis

Bitbucketには、プロセスを変更せずに2レベルのレビューを実施できるポリシー機能があります。

最も簡単なポリシーは、マージする前に数人が新機能やバグ修正を確認することを強制することです。たとえば、多くのチームは、少なくとも2人の開発者がコードをレビューして承認した場合にのみ、プルリクエストをマージできると判断します。チームは、レビュー担当者の数に上限を設定して、進行状況が遅くなりすぎないようにすることもできますが、忙しいチームメンバーがレビューの進行を妨げないように、最小承認制限よりも多くのレビュー担当者を招待すると便利な場合があります。

これは、アップグレードによって実装できます。

チームにプレミアムプランがある場合、リポジトリ管理者は、特定の数の承認を持たないプルリクエストがマージされるのを防ぐことができます。

または、コミットを検証するプラグインをインストールします。

コミットポリシープラグインは、Bitbucket Serverリポジトリにコミットされた変更を一連の設定可能なルール（コミットポリシー）と照合してチェックします。これは、JiraのコミットポリシープラグインをBitbucket Serverと統合することによって行われます。ポリシーが満たされない場合、コミットは拒否されます。拒否されたコミットは、「修正」して再コミットできます。

参照

3
Paul Sweatte