マージ前にチェックを提案または要求する
Bitbucket Premium
ユーザーにチェックを推奨し、全員にマージが許可されるようになる前に内容の検証を依頼できます。アトラシアンでは、プレミアム プラン向けのマージ チェックもいくつか提供しています。
マージ チェックを適用して、すべてのプル リクエストがマージされる前に完全に審査されていることを確認します。
プル リクエストのソース ブランチが変更される場合は、レビュアーに再度承認を要求します。
プル リクエストの差分に変更がない場合は承認を維持します。
マージ チェックでは、個別のブランチやブランチ パターンのマージについて、特定の条件を推奨または要求することができます。マージ チェックはブランチ権限と連携して機能し、柔軟性と開発ワークフローの制御機能をワークスペースのメンバーに提供します。
マージ チェックの目的
依存関係のマージ
ユーザーが成功したビルドのみを使用して変更をマージするようにします。
マージを行う前に成功すべきビルドの数を選択します。
ビルド ツール統合用 Marketplace アプリの Bitbucket Pipelines、またはコミット ステータスの REST API と併用します。
コードレビューの完了
マージをコードレビューに関連付けます。
同僚が協力してプル リクエストに取り組むようにします。
マージを行うために必要な作業を開発者が把握できるよう、ワークフローに一貫性を持たせます。
タスクの完了
プルリクエストでタスクを作成し、必要な変更をマークします。
プルリクエストが承認に進行するまで管理します。
マージの前にプルリクエストのすべてのタスクが完了していることを確認します。
マージ チェック
カスタムのマージ チェックを設定およびセットアップする方法
カスタムのマージ チェックを設定および設定するには、ワークスペース管理者である必要があります。詳細は「 カスタム マージ チェックのセットアップと使用」をご確認ください。
マージ チェックを使用して、マージ前に次の条件を推奨または要求できます。
プレミアム プランではない場合にこれらのいずれかのオプションを選択すると、未解決のマージ チェックがある状態でマージ可能なときに、ユーザーに警告が表示されます。ユーザーがマージを行うのを防ぐためには、プレミアムへアップグレードし、[未解決のマージ チェックがある場合はマージを行わない] を選択します。プレミアムの詳細についてはこちらをご参照ください。
設定 - 次の条件に当てはまるか確認 | 結果 |
|---|---|
承認の最小数 | プルリクエストの承認の数がその数を下回った場合、ユーザーに通知されます。 注意：プル リクエスト (PR) の作成者は自身の PR を承認できますが、その承認はマージ チェックの合格に必要な承認数にはカウントされません。 |
既定のレビュー担当者による承認の最小数 | プル リクエストの承認数がデフォルトのレビュアー数を下回った場合、ユーザーに通知されます。 |
変更がリクエストされていない | プル リクエストでレビュアーのいずれかに「変更をリクエスト済み」が関連付けられている場合は、ユーザーに通知されます。 |
未解決のプル リクエスト タスクがない | オープンなプルリクエストのタスクがあった場合、ユーザーに通知されます。 |
失敗したビルドも進行中のビルドもない、最後のコミットで成功したビルドの最小数 | 最後のコミットで成功したビルドの数がこの数を下回った場合、ユーザーに通知されます。 |
宛先ブランチの最大コミット数 | ブランチが宛先ブランチと比較して最大コミット数が少ないと、ユーザーに通知されます。 |
ソース ブランチが変更された際にリクエスト済みの変更をリセットする | ソース ブランチが変更されると「変更をリクエスト済み」ステータスを自動でリセットします。 |
ビルドが成功したら自動マージを許可 | 成功したビルド以外のすべての必須マージ チェックが完了したら、ビルドの完了を待たずに、ビルドの実行中に [マージ] を選択することができます。マージはビルドの成功後すぐに行われますが、ビルドに失敗するとブロックされます。 |
プレミアム プランの場合、次の設定にもアクセスできます。
設定 | 結果 |
|---|---|
ソース ブランチが変更されたら承認をリセットする | プルリクエストのソース ブランチに変更があった場合、プルリクエストは承認無しで更新され、レビューアはプルリクエストを再びレビューして承認する必要があります。 |
プル リクエストの差分に変更がない場合は承認を維持する | プル リクエストの既存の差分に変更がない場合でも、行われた承認がそのまま維持されるようにします。たとえば、空のコミットがブランチに追加されたり、ソース ブランチのリベース時に新しい変更が導入されなかったりする場合などです。 |
未解決のマージ チェックとのマージを防止する | プル リクエストに未解決のマージ チェックがある場合、ユーザーはマージできません。マージを実行する前に解決が必要な項目のチェックリストが表示されます。 |
セットアップの例
マージ チェックは、ブランチ権限と連携して個別ブランチまたはブランチ パターンに適用されます。このセクションの残りの部分では、ブランチ権限の説明に使用した例と、マージ チェックについて説明します。
たとえば、Alana (主任エンジニア)、Harvey (QA リード)、およびその他の 5 人のエンジニアが Teams in Space プロジェクトに携わっているとします。すべてのユーザーがリポジトリへの書き込みアクセス権を持っていますが、既定のブランチと開発ブランチへのアクセスを制限する必要があります。ブランチ権限ダイアログから、次のような権限を割り当てることができます。
ブランチ | ブランチの権限 | マージ チェック |
|---|---|---|
既定 | 書き込みアクセス権限: Alana プルリクエスト経由でのマージ: Alana、Harvey |
|
develop | 書き込みアクセス権限: Alana、Harvey プルリクエスト経由でのマージ: Alana、Harvey、 |
|
最初にブランチ制限を追加するリポジトリに移動し、[リポジトリの設定] > [Branch restrictions (ブランチ制限)] の順にクリックします。
main ブランチにブランチ権限とマージ チェックを追加する
[Add a branch restriction (ブランチ制限を追加)] をクリックします。
各フィールドに以下を入力します。
ブランチまたはパターン: main
[ブランチ権限] タブの [Write access (書き込みアクセス)] で、[Only specific people or groups have write access (特定のユーザーまたはグループのみが書き込みアクセス権を持つ)] を選択します: Alana (Alana はプル リクエスト経由でのマージ権限を自動的に取得します)
[ブランチ権限]タブの [Merge access via pull requests (プル リクエスト経由のマージ アクセス)] で、[Only specific people or groups have merge access (特定のユーザーまたはグループのみがマージ アクセス権を持つ)] を選択します: Harvey
[マージ チェックの追加] を展開します。
[Minimum number of successful builds for the last commit with no failed builds (最後のコミットで失敗したビルドがない成功したビルドの最小数)]を選択します。
ドロップダウンから 2 を選択します。
[保存] をクリックします。
このセットアップによって、ワークスペースのメンバーは main ブランチへのアクセスをコントロールできます。本番対応のコードのみを main にマージするため、成功したビルドに対してのみマージ チェックを行います。
develop ブランチにブランチ権限とマージ チェックを追加する
[Add a branch restriction (ブランチ制限を追加)] をクリックします。
各フィールドに以下を入力します。
ブランチまたはパターン: develop
[ブランチ権限] タブの [Write access (書き込みアクセス)] で、[Only specific people or groups have write access (特定のユーザーまたはグループのみが書き込みアクセス権を持つ)] を選択します: Alana および Harvey ペルソナ (Alana と Harvey はプル リクエスト経由でのマージ権限を自動的に取得します)
[ブランチ権限] タブの [Merge access via pull requests (プル リクエスト経由でのマージ アクセス)] で、[Only specific people or groups have merge access (特定のユーザーまたはグループのみがマージ アクセス権を持つ)] を選択します: teamsinspace:developers
[Merge settings (マージ設定)] タブを選択し、次を選択します。
[Minimum number of approvals (承認の最小数)]を選択し、ドロップダウンから [2] を選択します。
[Minimum number of approvals from default reviewers (既定のレビュアーによる承認の最小数)] を選択し、既定のレビュアーの数を選択します。これがプル リクエストに対して設定されている場合、プル リクエストを承認する必要があります。
[No unresolved pull request tasks (未解決のプル リクエスト タスクはありません)] を選択します。
[Minimum number of successful builds for the last commit with no failed builds (最後のコミットで失敗したビルドがない成功したビルドの最小数)]を選択し、ドロップダウンから [3] を選択します。
保存をクリックします。
この内容はお役に立ちましたか?