マージ前にチェックを提案または要求する

Bitbucket Premium

ユーザーにチェックを推奨し、全員にマージが許可されるようになる前に内容の検証を依頼できます。アトラシアンでは、プレミアム プラン向けのマージ チェックもいくつか提供しています。

  • マージ チェックを適用して、すべてのプル リクエストがマージされる前に完全に審査されていることを確認します。

  • プル リクエストのソース ブランチが変更される場合は、レビュアーに再度承認を要求します。

    • プル リクエストの差分に変更がない場合は承認を維持します。

Bitbucket プレミアムについて詳細を読む

マージ チェックでは、個別のブランチやブランチ パターンのマージについて、特定の条件を推奨または要求することができます。マージ チェックはブランチ権限と連携して機能し、柔軟性と開発ワークフローの制御機能をワークスペースのメンバーに提供します。

マージ チェックの目的

依存関係のマージ

コードレビューの完了

  • マージをコードレビューに関連付けます。

  • 同僚が協力してプル リクエストに取り組むようにします。

  • マージを行うために必要な作業を開発者が把握できるよう、ワークフローに一貫性を持たせます。

タスクの完了

  • プルリクエストでタスクを作成し、必要な変更をマークします。

  • プルリクエストが承認に進行するまで管理します。

  • マージの前にプルリクエストのすべてのタスクが完了していることを確認します。

マージ チェック

マージ チェックを使用して、マージ前に次の条件を推奨または要求できます。

プレミアム プランではない場合にこれらのいずれかのオプションを選択すると、未解決のマージ チェックがある状態でマージ可能なときに、ユーザーに警告が表示されます。ユーザーがマージを行うのを防ぐためには、プレミアムへアップグレードし、[未解決のマージ チェックがある場合はマージを行わない] を選択します。プレミアムの詳細についてはこちらをご参照ください。

設定

結果

承認が {#} 以上あるかどうかをチェック

プルリクエストの承認の数がその数を下回った場合、ユーザーに通知されます。

既定のレビュアーからの承認が {#} 以上あるかどうかをチェック

プル リクエストの承認数がデフォルトのレビュアー数を下回った場合、ユーザーに通知されます。

変更がリクエストされていないことを確認する

プル リクエストでレビュアーのいずれかに「変更をリクエスト済み」が関連付けられている場合は、ユーザーに通知されます。

未解決のプルリクエストのタスクをチェック

オープンなプルリクエストのタスクがあった場合、ユーザーに通知されます。

直近のコミットで {#} 個のビルドがパスして、失敗したビルドがないことをチェックする

最後のコミットで成功したビルドの数がこの数を下回った場合、ユーザーに通知されます。

ソース ブランチが変更された際にリクエスト済みの変更をリセットする

ソース ブランチが変更されると「変更をリクエスト済み」ステータスを自動でリセットします。

すべてのチェックを通過したプル リクエストを自動的にマージ

PR の作成者または管理者がこの機能を有効化し、すべてのマージ チェックを通過したら保留中のマージを自動的にトリガーするようにできます。

プレミアム プランの場合、次の設定にもアクセスできます。

設定

結果

ソース ブランチが変更されたら承認をリセットする

プルリクエストのソース ブランチに変更があった場合、プルリクエストは承認無しで更新され、レビューアはプルリクエストを再びレビューして承認する必要があります。

プル リクエストの差分に変更がない場合は承認を維持する

プル リクエストの既存の差分に変更がない場合でも、行われた承認がそのまま維持されるようにします。たとえば、空のコミットがブランチに追加されたり、ソース ブランチのリベース時に新しい変更が導入されなかったりする場合などです。

マージ チェックを適用して、すべてのプル リクエストがマージされる前に完全に審査されていることを確認します。

プル リクエストに未解決のマージ チェックがある場合、ユーザーはマージできません。マージを実行する前に解決が必要な項目のチェックリストが表示されます。

セットアップの例

マージ チェックは、ブランチ権限と連携して個別ブランチまたはブランチ パターンに適用されます。このセクションの残りの部分では、ブランチ権限の説明に使用した例と、マージ チェックについて説明します。

たとえば、Alana (主任エンジニア)、Harvey (QA リード)、およびその他の 5 人のエンジニアが Teams in Space プロジェクトに携わっているとします。すべてのユーザーがリポジトリへの書き込みアクセス権を持っていますが、既定のブランチと開発ブランチへのアクセスを制限する必要があります。ブランチ権限ダイアログから、次のような権限を割り当てることができます。

ブランチ

ブランチの権限

マージ チェック

既定

書き込みアクセス権限: Alana

プルリクエスト経由でのマージ: Alana、Harvey

  • 最後のコミットで 2 件のビルドが成功していることをチェック

develop

書き込みアクセス権限: Alana、Harvey

プルリクエスト経由でのマージ: Alana、Harvey、
teamsinspace:developers (グループ)

  • 最後のコミットで 3 件のビルドが成功していることをチェック

  • 承認が 2 つ以上あることをチェック

  • 未解決のプルリクエストのタスクをチェック

最初にブランチ制限を追加するリポジトリに移動し、[リポジトリの設定] > [Branch restrictions (ブランチ制限)] の順にクリックします。

main ブランチにブランチ権限とマージ チェックを追加する

  1. [Add a branch restriction (ブランチ制限を追加)] をクリックします。

  2. 各フィールドに以下を入力します。

    1. ブランチまたはパターン: main

    2. [ブランチ権限] タブの [Write access (書き込みアクセス)] で、[Only specific people or groups have write access (特定のユーザーまたはグループのみが書き込みアクセス権を持つ)] を選択します: Alana (Alana はプル リクエスト経由でのマージ権限を自動的に取得します)

    3. [ブランチ権限]タブの [Merge access via pull requests (プル リクエスト経由のマージ アクセス)] で、[Only specific people or groups have merge access (特定のユーザーまたはグループのみがマージ アクセス権を持つ)] を選択します: Harvey

  3. [マージ チェックの追加] を展開します。

    1. [Minimum number of successful builds for the last commit with no failed builds (最後のコミットで失敗したビルドがない成功したビルドの最小数)]を選択します。

    2. ドロップダウンから 2 を選択します。

  4. [保存] をクリックします。

このセットアップによって、ワークスペースのメンバーは main ブランチへのアクセスをコントロールできます。本番対応のコードのみを main にマージするため、成功したビルドに対してのみマージ チェックを行います。

develop ブランチにブランチ権限とマージ チェックを追加する

  1. [Add a branch restriction (ブランチ制限を追加)] をクリックします。

  2. 各フィールドに以下を入力します。

    1. ブランチまたはパターン: develop

    2. [ブランチ権限] タブの [Write access (書き込みアクセス)] で、[Only specific people or groups have write access (特定のユーザーまたはグループのみが書き込みアクセス権を持つ)] を選択します: Alana および Harvey ペルソナ (Alana と Harvey はプル リクエスト経由でのマージ権限を自動的に取得します)

    3. [ブランチ権限] タブの [Merge access via pull requests (プル リクエスト経由でのマージ アクセス)] で、[Only specific people or groups have merge access (特定のユーザーまたはグループのみがマージ アクセス権を持つ)] を選択します: teamsinspace:developers

  3. [Merge settings (マージ設定)] タブを選択し、次を選択します。

    1. [Minimum number of approvals (承認の最小数)]を選択し、ドロップダウンから [2] を選択します。

    2. [Minimum number of approvals from default reviewers (既定のレビュアーによる承認の最小数)] を選択し、既定のレビュアーの数を選択します。これがプル リクエストに対して設定されている場合、プル リクエストを承認する必要があります。

    3. [No unresolved pull request tasks (未解決のプル リクエスト タスクはありません)] を選択します。

    4. [Minimum number of successful builds for the last commit with no failed builds (最後のコミットで失敗したビルドがない成功したビルドの最小数)]を選択し、ドロップダウンから [3] を選択します。

  4. 保存をクリックします。

その他のヘルプ