ブランチ保護ルールを管理する

ブランチ保護ルールを作成して、1 つ以上のブランチに特定のワークフローを強制することができます。たとえば、承認レビューを要求したり、保護されたブランチにマージされるすべての pull request について状態チェックを渡したりすることができます。

この機能を使用できるユーザーについて

People with admin permissions or a custom role with the "edit repository rules" permission to a repository can manage branch protection rules.

保護されたブランチは、組織の GitHub Free と GitHub Free のパブリック リポジトリで使用できます。 保護されたブランチは、GitHub Pro、GitHub Team、GitHub Enterprise Cloud、GitHub Enterprise Server のパブリック リポジトリとプライベート リポジトリでも使用できます。詳しくは、「GitHub のプラン」をご覧ください。

この記事の内容

ブランチ保護ルールについて

リポジトリ内のブランチ保護ルールは、特定のブランチ、すべてのブランチ、または fnmatch 構文で指定する名前のパターンに一致するあらゆるブランチに対して作成できます。 たとえば、release という単語を含む任意のブランチを保護するには、*release* のブランチ ルールを作成します。

ワイルドカード構文 * を使用して、リポジトリ内の現在および将来のブランチすべてに対する規則を作成できます。 GitHub では File::FNM_PATHNAME フラグを File.fnmatch 構文で使うため、* のワイルドカードがディレクトリの区切り記号 (/) と照合されません。 たとえば、qa/* は、qa/ で始まり、1 つのスラッシュを含むすべてのブランチと照合されますが、qa/foo/bar とは照合されません。 qa の後には、qa/**/* を使用して任意の数のスラッシュを含めることができます。これは、たとえば qa/foo/bar/foobar/hello-world と一致します。 qa**/**/* を使い qa の文字列を拡張して、より包括的にすることもできます。

構文のオプションについて詳しくは、fnmatch のドキュメントを参照してください。

リポジトリが同じブランチに影響する複数の保護されたブランチのルールを持っているなら、特定のブランチ名を含むルールがもっとも高い優先順位を持ちます。 同じ特定のブランチ名を参照する保護されたブランチのルールが複数あるなら、最初に作成されたブランチルールが高い優先順位を持ちます。

*、?、] などの特殊文字を含む、保護されたブランチのルールは、作成された順序で適用されるので、これらの文字が含まれる規則は古い方が高い優先順位を持ちます。

既存のブランチのルールに例外を作成するため、特定のブランチ名に対するルールなど、優先度の高いブランチ保護ルールを新しく作成できます。

使用可能なブランチ保護設定それぞれの詳細については、「保護されたブランチについて」を参照してください。

Note

一度に適用できるブランチ保護ルールは 1 つだけです。これは、複数のルールのバージョンで同じブランチを対象にすると、適用されるルールがわかりにくいためです。 さらに、組織内の複数のリポジトリに適用されるルールのセットを 1 つ作成することもできます。 ブランチ保護ルールの代わりになるものについて詳しくは、「ルールセットについて」をご覧ください。

ブランチ保護ルールを作成する

ブランチのルールを作成する際に、指定したブランチがリポジトリにしている必要はありません。

Note

アクターをバイパス リストに追加できるのは、リポジトリが組織に属している場合のみです。

  1. GitHub で、リポジトリのメイン ページに移動します。

  2. リポジトリ名の下にある [設定] をクリックします。 [設定] タブが表示されない場合は、 [] ドロップダウン メニューを選び、 [設定] をクリックします。

    タブを示すリポジトリ ヘッダーのスクリーンショット。 [設定] タブが濃いオレンジ色の枠線で強調表示されています。

  3. サイド バーの [コードと自動化] セクションで、 [ ブランチ] をクリックします。

  4. [ブランチ保護のルール] の横にある [ルールの追加] をクリックします。

  5. "Branch name pattern（ブランチ名のパターン）"の下で、保護したいブランチの名前もしくはパターンを入力してください。

  6. 必要に応じて、必須の pull request を有効化します。

    Note

    [新たなコミットがプッシュされたときに古い pull request の承認を却下する] や [最新のレビュー可能なプッシュの承認を要求する] を選んだ場合、マージの内容が pull request の GitHub によって生成されたマージと完全に一致しない限り、pull request に対するマージ コミットを手動で作成してそれを保護されたブランチに直接プッシュする操作は失敗します。

    さらに、これらの設定では、レビューの送信後に新しい変更がマージ ベースに導入された場合、レビューの承認は古いものとして無視されます。 マージ ベースは、トピック ブランチとベース ブランチの間で共通の最後の先祖であるコミットです。 マージ ベースが変更された場合、他のユーザーが作業をもう一度承認するまで、pull request をマージすることはできません。

    • Protect matching branches で、 [Require a pull request before merging](マージ前に pull request 必須) を選択します。

    • 必要に応じて、pull request をマージできるように承認を要求するには、 [承認を要求する] を選びます。

      [マージ前に必要な承認回数] ドロップダウン メニューを選び、ブランチで必要な承認レビューの回数をクリックします。

    • 必要に応じて、コードを変更するコミットがブランチにプッシュされたときに pull request 承認レビューを却下するには、 [Dismiss stale pull request approvals when new commits are pushed](新しいコミットがプッシュされたときに古い pull request 承認を却下する) を選択します。

    • 必要に応じて、pull request が影響するコードに所有者が指定されているとき、コード所有者のレビューを必須にするには、 Require review from Code Owners を選択します。 コードに複数のオーナーが存在する場合、この要件を満たすには、_いずれか_のコード オーナーからの承認で十分であることに注意してください。 詳しくは、「コードオーナーについて」を参照してください。

    • 必要に応じて、pull request が必須であるときに、特定のアクターがそれを作成せずにコードをブランチにプッシュできるようにするには、 [Allow specified actors to bypass required pull requests](指定したアクターが必須 pull request をバイパスすることを許可) を選択します。 次に、pull request の作成をスキップすることを許可するアクターを探して選択します。

    • 必要に応じて、リポジトリが組織に含まれる場合に、 [Restrict who can dismiss pull request reviews](pull request レビューを却下できるユーザーを制限) を選択します。 次に、検索フィールドで pull request レビューを却下できるアクターを探して選びます。 詳しくは、「プルリクエストレビューの却下」を参照してください。

    • 必要に応じて、最後のユーザー以外のユーザーに、ブランチにプッシュしてマージ前に pull request を承認するよう要求するには、 [最新のレビュー可能なプッシュを要求する] を選びます。 詳しくは、「保護されたブランチについて」を参照してください。

  7. 必要に応じて、ステータスチェック必須を有効化します。 詳しくは、「ステータスチェックについて」を参照してください。

  8. 必要に応じて、 Require conversation resolution before merging を選択します。

  9. 必要に応じて、 Require signed commits を選択します。

  10. 必要に応じて、 Require linear history を選択します。

  11. 必要に応じて、マージ キューを使用して pull request をマージするには、 [Require merge queue](マージ キュー必須) を選択します。 マージ キューについて詳しくは、「マージキューの管理」を参照してください。

  12. 必要に応じて、マージ前に変更を正常にデプロイする必要がある環境を選択するには、 Require deployments to succeed before merging を選択してから環境を選択します。

  13. 必要に応じて、ブランチを読み取り専用にします。

    • [ブランチをロックする] を選びます。
    • 必要に応じて、フォークの同期を許可するには、 [フォークの同期を許可する] をオンにします。

  14. 必要に応じて、[上記の設定をバイパスすることを許可しない] を選択します。

  15. 必要に応じて、GitHub Free 組織によって所有されているパブリック リポジトリと、GitHub Team または GitHub Enterprise Cloud を使って組織によって所有されているすべてのリポジトリで、ブランチ制限を有効にします。

    • Restrict who can push to matching branches を選択します。
    • 必要に応じて、一致するブランチの作成も制限するには、 Restrict pushes that create matching branches を選択します。
    • 検索フィールドで、保護されたブランチにプッシュするためのアクセス許可や一致するブランチを作成するためのアクセス許可が付与されるユーザー、Team、またはアプリを探して選びます。

  16. 必要に応じて、Rules applied to everyone including administrators の下で [Allow force pushes](フォース プッシュを許可) を選択します。

    次に、ブランチにフォース プッシュできるユーザーを選びます。

    • Everyone を選択し、リポジトリに対して少なくとも書き込みアクセス許可を持つすべてのユーザー (管理者権限を持つユーザーを含む) が、ブランチにフォース プッシュできるようにします。
    • [Specify who can force push](フォース プッシュできるユーザーを指定する) を選択し、ブランチへのフォース プッシュを特定のアクターに許可します。 次に、そのようなアクターを探して選択します。

    フォース プッシュについて詳しくは、「保護されたブランチについて」をご覧ください。

  17. 必要に応じて、 Allow deletions を選択します。

  18. Create をクリックしてください。

ブランチ保護ルールを編集する

  1. GitHub で、リポジトリのメイン ページに移動します。

  2. リポジトリ名の下にある [設定] をクリックします。 [設定] タブが表示されない場合は、 [] ドロップダウン メニューを選び、 [設定] をクリックします。

    タブを示すリポジトリ ヘッダーのスクリーンショット。 [設定] タブが濃いオレンジ色の枠線で強調表示されています。

  3. サイド バーの [コードと自動化] セクションで、 [ ブランチ] をクリックします。

  4. 編集しようとするブランチ保護規則の右側の [編集] をクリックします。

  5. ブランチ保護ルールを自由に変更してください。

  6. [変更を保存] をクリックします。

ブランチ保護ルールを削除する

  1. GitHub で、リポジトリのメイン ページに移動します。

  2. リポジトリ名の下にある [設定] をクリックします。 [設定] タブが表示されない場合は、 [] ドロップダウン メニューを選び、 [設定] をクリックします。

    タブを示すリポジトリ ヘッダーのスクリーンショット。 [設定] タブが濃いオレンジ色の枠線で強調表示されています。

  3. サイド バーの [コードと自動化] セクションで、 [ ブランチ] をクリックします。

  4. 削除しようとするブランチ保護規則の右側の [削除] をクリックします。