> For the complete documentation index, see [llms.txt](https://docs.flosum.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.flosum.com/devops/devops-ja/she-ding/pururikuesuto/pururikuesutorruno.md).
# プルリクエスト承認ルールの追加
{% hint style="warning" %}
#### 旧UI向けに作成
この記事は旧UI向けに作成されました。手順は今でも使用できますが、スクリーンショットは古くなっています。場合によっては、手順で参照されている項目が移動または変更されていることがあります。項目が見つからない場合は、 [どこに行ったのか](/devops/devops-ja/shii-uiux-heno/dokonittanoka.md) 記事。
{% endhint %}
##  概要
この記事では、Pull Request 承認ルールの仕組みと追加方法を説明します。既定では、Pull Request はマージされる前にレビューを必要としません。Pull Request 承認ルールを使用すると、管理者は Pull Request をマージする前に必要な承認の最小数を強制できます。各ルールでは、どのブランチに適用されるかと、必要な承認数を定義します。Pull Request のターゲット ブランチによって、必要な承認数が決まります。
ルールは、さまざまなスコープで構成できます：
* **すべてのブランチ**：このルールは、より具体的なルールで対象外となっている任意のブランチに適用されます。
* **次を選択**：このルールは、明示的に選択した 1 つ以上のブランチを対象にします。
* **パターン**：このルールはワイルドカード構文を使用して、命名規則に基づいてブランチを一致させます（例： `feature/*`, `release/v*`, `hotfix-*`).
{% hint style="info" %}
**Pull Request 承認ルールを上書きする**
Pull Request 承認ルールは上書きできません。ルールがターゲット ブランチに適用される場合、必要な人数のレビュー担当者が承認するまで Pull Request はマージできません。これは意図された動作です。ただし、Pull Request 承認ルールを回避する正式な方法が 2 つあります：
* 次のいずれかを実行します **Smart Merge**。これにはレビューは不要です。
* 変更する **Pull Request 承認ルール**.
{% endhint %}
### Pull Request の例
次のスクリーンショットは、承認ルールが適用された Pull Request を示しています。
### ルールの階層
ルールで選択されたブランチが別のルールと重複する場合、優先順位によって重複するブランチにどのルールが適用されるかが決まります。優先順位の高い順から低い順は次のとおりです：
* **次を選択** > **パターン** > **すべてのブランチ**
次のスクリーンショットには 2 つのルールが示されています。1 つは **すべてのブランチ**に適用され、もう 1 つは **main** ブランチのみに適用されます。 **次を選択** ルールが **すべてのブランチ** ルールよりも優先されるため、 **main** ブランチを対象とする Pull Request は、他のブランチで必要な 1 件の承認ではなく、3 件の承認が必要です。
{% hint style="info" %}
**特殊なケース**
その **次を選択** オプションでは、同じブランチを複数のルールに割り当てることはできません。これにより、ブランチ **X** に対して 1 つのルールは 3 件の承認を必要とし、別のルールは 1 件だけを必要とする、といった競合を防ぎます。
その **パターン** オプションでは、重複するパターンを持つ複数のルールを保存できません。たとえば、次の両方を保存することはできません： `feature/*` と `feature/new*`。なぜなら、 `feature/*` パターンにはすでに `feature/new*` パターンが含まれているからです。
{% endhint %}
## 承認ルールの追加
{% stepper %}
{% step %}
### 承認ルールを有効化
1. 次をクリックします **設定** を左側のサイドバーメニューから。
2. 次をクリックします **一般** タブに表示されます。
3. 次をクリックします **プルリクエスト**.
4. 無効になっている場合は、 **有効化** トグルをクリックして承認ルールを有効にします。
{% endstep %}
{% step %}
### ブランチの選択
承認ルールを適用するブランチを選択する方法は 3 つあります。
**すべてのブランチ**
この選択では、ルールが DevOps テナント内のすべてのブランチに適用されます。
1. 選択してください **すべてのブランチ** オプション。
**次を選択**
この選択では、リストから選択したブランチのみにルールが適用されます。
1. 選択してください **次を選択** オプション。
2. 次をクリックします **ブランチを選択** のドロップダウンメニュー。
3. このルールを適用する各ブランチを選択します。
{% hint style="info" %}
選択した各ブランチの右側にチェックマークが表示されます。ドロップダウンには、選択済みブランチ数と利用可能なブランチ数も表示されます。ブランチが多い場合は、検索ボックスを使用して見つけてください。
{% endhint %}
**パターン**
この選択では、入力したパターンに一致するブランチにルールが適用されます。パターンの末尾にワイルドカード文字（\*）を追加すると、指定したパターンで始まり、後ろに任意の文字が続くブランチに一致させることができます。たとえば、次のパターンを使用すると、 `feature/*`下の表に、このルールがブランチにどのように影響するかが示されます。
| ブランチ | ルール適用済み |
|---|
| main |  |
| feature/addAccount |  |
| feature/removeAccount | |
| release/v1.2.3 | |
1. 選択してください **パターン** オプション。
2. テキストボックスに、このルールに使用するパターンを入力します。
{% endstep %}
{% step %}
### 承認数の設定
その **承認数** は、Pull Request をマージする前に承認しなければならないレビュー担当者の人数です。数は 1 以上である必要があります。
1. このルールに必要な承認数を **承認数** テキストボックスに入力します。
{% endstep %}
{% step %}
### ルールの追加
Pull Request の設定に複数の承認ルールを追加できます。複数のルールで選択されたブランチにどのルールが適用されるかについては、 **ルールの階層** 上記のセクションを参照してください。
1. 次をクリックします **ルールを追加**.
2. 上記の手順に従って、ルールのブランチ選択と承認数を構成します。
{% endstep %}
{% step %}
### ルールを保存
Pull Request 承認ルールの定義が完了したら、新規およびアクティブな Pull Request に適用される前に、保存する必要があります。
1. 次をクリックします **保存**.
{% endstep %}
{% endstepper %}
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.flosum.com/devops/devops-ja/she-ding/pururikuesuto/pururikuesutorruno.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
