{"meta":{"title":"保護されたブランチについて","intro":"重要なブランチを保護するには、ブランチ保護ルールを設定します。このルールは、コラボレータがブランチへのプッシュを削除または強制できるかどうかを定義し、ステータスチェックのパスや直線状のコミット履歴など、ブランチへのプッシュの要件を設定します。","product":"リポジトリ","breadcrumbs":[{"href":"/ja/repositories","title":"リポジトリ"},{"href":"/ja/repositories/configuring-branches-and-merges-in-your-repository","title":"ブランチとマージ"},{"href":"/ja/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches","title":"保護されたブランチを管理する"},{"href":"/ja/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches","title":"保護されたブランチについて"}],"documentType":"article"},"body":"# 保護されたブランチについて\n\n重要なブランチを保護するには、ブランチ保護ルールを設定します。このルールは、コラボレータがブランチへのプッシュを削除または強制できるかどうかを定義し、ステータスチェックのパスや直線状のコミット履歴など、ブランチへのプッシュの要件を設定します。\n\n## ブランチ保護ルールについて\n\n> \\[!TIP] 特定のステータス チェックを必要とするブランチ保護規則を使う場合は、ジョブ名がすべてのワークフローで一意であることをチェックします。 複数のワークフローで同じジョブ名を使うと、ステータス チェックの結果があいまいになり、pull request のマージが禁止される可能性があります。 「[ステータスチェックについて](/ja/pull-requests/collaborating-with-pull-requests/collaborating-on-repositories-with-code-quality-features/about-status-checks)」を参照してください。\n\nブランチ保護ルールを作成することにより、コラボレータがリポジトリ内のブランチに変更をプッシュする前に、特定のワークフローまたは要件を適用できます。これには、プルリクエストのブランチへのマージが含まれます。 アクターをバイパス リストに追加できるのは、リポジトリが組織に属している場合のみです。\n\nデフォルト設定では、各ブランチ保護ルールは、一致するブランチへのフォースプッシュを無効にし、一致するブランチが削除されないようにします。 必要に応じて、これらの制限を無効にし、追加のブランチ保護設定を有効にすることができます。\n\n既定では、ブランチ保護ルールの制限は、リポジトリの管理者アクセス許可を持つユーザーまたは \\[ブランチ保護をバイパスする] アクセス許可を持つカスタム役割には適用されません。 必要に応じて、管理者および \"ブランチ保護をバイパスする\" アクセス許可を持つロールにも、制限を適用できます。 詳しくは、「[組織のカスタムリポジトリロールの管理](/ja/enterprise-cloud@latest/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/managing-custom-repository-roles-for-an-organization)」をご覧ください。\n\nリポジトリ内のブランチ保護ルールは、特定のブランチ、すべてのブランチ、または `fnmatch` 構文で指定する名前のパターンに一致するあらゆるブランチに対して作成できます。 たとえば、`release` という単語を含む任意のブランチを保護するには、`*release*` のブランチ ルールを作成します。 ブランチ名のパターンの詳細については、「[ブランチ保護ルールを管理する](/ja/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/managing-a-branch-protection-rule)」を参照してください。\n\nすべてのマージの要件が満たされたときに、自動的にマージされるようにPull Requestを設定できます。 詳しくは、「[プルリクエストを自動的にマージする](/ja/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/automatically-merging-a-pull-request)」をご覧ください。\n\n> \\[!NOTE]\n> 一度に適用できるブランチ保護ルールは 1 つだけです。これは、ルールの複数のバージョンで同じブランチを対象にすると、適用されるルールがわかりにくいためです。 ブランチ保護ルールの代わりになるものの詳細については、「[ルールセットについて](/ja/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets)」を参照してください。\n\n## ブランチ保護設定について\n\nブランチ保護ルールごとに、次の設定を有効にするか無効にするかを選択できます。\n\n* [\\[Require pull request reviews before merging\\](マージ前に pull request レビュー必須)](#require-pull-request-reviews-before-merging)\n* [マージ前にステータスチェック必須](#require-status-checks-before-merging)\n* [\\[Require conversation resolution before merging\\] (マージ前に会話の解決必須)](#require-conversation-resolution-before-merging)\n* [\\[Require signed commits\\] (署名済みコミット必須)](#require-signed-commits)\n* [線形履歴を要求する](#require-linear-history)\n* [マージキューの要求](#require-merge-queue)\n* [マージする前にデプロイが成功することを要求する](#require-deployments-to-succeed-before-merging)\n* [ブランチをロック](#lock-branch)\n* [上記の設定をバイパスすることを許可しない](#do-not-allow-bypassing-the-above-settings)\n* [\\[Restrict who can push to matching branches\\](一致するブランチにプッシュできるユーザーを制限)](#restrict-who-can-push-to-matching-branches)\n* [フォース プッシュを許可](#allow-force-pushes)\n* [\\[Allow deletions\\] (削除を許可)](#allow-deletions)\n\nブランチ保護を設定する方法の詳細については、「[ブランチ保護ルールを管理する](/ja/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/managing-a-branch-protection-rule)」を参照してください。\n\n### \\[Require pull request reviews before merging]\\(マージ前に pull request レビュー必須)\n\nリポジトリ管理者または \"リポジトリ ルールの編集\" アクセス許可を持つカスタム ロールは、すべての pull request について、ユーザーが pull request を保護されたブランチにマージするには、その前に特定の数のレビュー承認を受け取る必要があるようにすることができます。 リポジトリに書き込み権限を持っている人か、指定されたコードオーナーからの承認レビューを必須とすることができます。\n\n必須レビューを有効にした場合、コラボレータは、書き込み権限を持つ必要な人数のレビュー担当者により承認されたプルリクエストからしか、保護されたブランチに変更をプッシュできなくなります。\n\n管理者権限を持つユーザーがレビューで **[Request changes](変更の要求)** オプションを選択した場合、pull request をマージするためには、そのユーザーがその pull request を承認する必要があります。 プルリクエストへの変更をリクエストしたレビュー担当者の手が空いていない場合、そのリポジトリに書き込み権限を持つ人が、ブロックしているレビューを却下できます。\n\nすべての必須のレビュー担当者がPull Requestを承認した後でも、同じコミットを指すヘッドブランチを持つ、保留中もしくは拒否されたレビューを持つオープンなPull Requestが他にある場合、コラボレータはそのPull Requestをマージできません。 まず、他のPull Request上のブロックしているレビューを、書き込み権限を持つ誰かが承認もしくは却下しなければなりません。\n\nコラボレータが保留中または拒否されたレビューのプルリクエストを保護されたブランチにマージしようとすると、コラボレータにエラーメッセージが届きます。\n\n```shell\nremote: error: GH006: Protected branch update failed for refs/heads/main.\nremote: error: Changes have been requested.\n```\n\n必要に応じて、pull request の差分に影響するコミットがプッシュされたときに、古い pull request の承認を無視することを選べます。 GitHub は、pull request が承認された時点での diff の状態を記録します。 この状態は、レビュー担当者が承認した一連の変更を表します。 この状態から diff が (たとえば、共同作成者が pull request ブランチに新しい変更をプッシュしたか、**\\[ブランチを更新]** をクリックしたため、または関連する pull request がターゲット ブランチにマージされたために) 変更された場合、承認レビューは古いものとして無視され、誰かが作業をもう一度承認するまで pull request をマージすることはできません。 ベース ブランチの詳細については、「[pull requests について](/ja/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests)」を参照してください。\n\n必要に応じて、プルリクエストレビューを却下する権限を、特定の人物またはチームに限定できます。 詳しくは、「[プルリクエストレビューの却下](/ja/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/dismissing-a-pull-request-review)」をご覧ください。\n\n必要に応じて、コードオーナー'からのレビューを必須にすることもできます。 この場合、コードオーナーのコードに影響するプルリクエストは、保護されたブランチにプルリクエストをマージする前に、そのコードオーナーから承認される必要があります。\n\n必要に応じて、最新のレビュー可能なプッシュは、プッシュしたユーザー以外のユーザーが承認することを必須にすることができます。 これは、少なくとももう 1 人の許可されたレビュー担当者が変更を承認済みであることを意味します。 たとえば、\"最後のレビュー担当者\" は、最新の一連の変更が他のレビューからのフィードバックを組み込み、未確認の新しいコンテンツを追加しないことを確認できます。\n\n多くのレビューを必要とする複雑な pull request、プッシュするには最後の担当者以外の担当者からの承認が必須とすることで、すべての古いレビューを無視する必要性を回避できる妥協策になります。このオプションを使用すると、\"古い\" レビューは無視されず、最新の変更を行ったユーザー以外の誰かによって承認されている限り、pull request は承認済みのままになります。 pull request を既にレビューしているユーザーは、最後のプッシュの後でもう一度承認して、この要件を満たすことができます。 pull request が \"ハイジャックされる\" (承認された pull request に未承認のコンテンツが追加される) ことに懸念がある場合は、古いレビューを無視する方が安全です。\n\n> \\[!NOTE] **\\[新たなコミットがプッシュされたときに古い pull request の承認を却下する]** や **\\[最新のレビュー可能なプッシュの承認を要求する]** を選んだ場合、マージの内容が pull request の GitHub によって生成されたマージと完全に一致しない限り、pull request に対するマージ コミットを手動で作成してそれを保護されたブランチに直接プッシュする操作は失敗します。\n>\n> さらに、これらの設定では、レビューの送信後に新しい変更がマージ ベースに導入された場合、レビューの承認は古いものとして無視されます。 マージ ベースは、トピック ブランチとベース ブランチの間で共通の最後の先祖であるコミットです。 マージ ベースが変更された場合、他のユーザーが作業をもう一度承認するまで、pull request をマージすることはできません。\n\n### マージ前にステータスチェック必須\n\n保護されたブランチにコラボレーターが変更を加える前に、必須のステータス チェックの状態が `successful`、`skipped`、または `neutral` になっている必要があります。 必須の状態チェックは、チェックまたはコミット状態にすることができます。 詳しくは、「[ステータスチェックについて](/ja/pull-requests/collaborating-with-pull-requests/collaborating-on-repositories-with-code-quality-features/about-status-checks)」をご覧ください。\n\nコミット ステータス API を使用して、外部サービスが適切な状態のコミットにマークを付けることを許可できます。 詳しくは、「[コミットのステータス用の REST API エンドポイント](/ja/rest/commits/statuses)」をご覧ください。\n\n必須ステータスチェックを有効にした後、すべての必須ステータスチェックが合格しない限り、コラボレータは保護されたブランチに変更をマージできません。 必須ステータスチェックをパスしたら、コミットを別のブランチにプッシュしてから、マージするか、保護されたブランチに直接プッシュする必要があります。\n\nリポジトリへの書き込み権限があるユーザーまたは統合は、リポジトリのステータス チェックを任意の状態に設定できますが、場合によっては特定の GitHub App のステータス チェックのみを受け入れる必要があります。 必須状態チェックを追加するとき、このチェックを最近設定したアプリを、状態更新が想定されるソースとして選べます。 状態が他のユーザーまたは統合によって設定されている場合、マージは許可されません。 [any source](任意のソース) を選択した場合は、マージ ボックスに一覧表示されている各状態の作成者を引き続き手動で確認することができます。\n\n必須ステータスチェックのタイプは、\\[loose] (寛容)、\\[strict] (厳格) のいずれかに設定できます。 選択した必須ステータスチェックのタイプにより、マージする前にブランチをベースブランチとともに最新にする必要があるかどうかが決まります。\n\n| 必須ステータスチェックのタイプ | 設定 | マージの要件 | 考慮事項 |\n| --------------- | -- | ------ | ---- |\n| **Strict**      |    |        |      |\n\n```\n          **[Require branches to be up to date before merging](マージ前にブランチの最新状態必須)** チェックボックスをオンにします。 | ブランチは、マージ前にベース ブランチと同じ最新状態である**必要があります**。 | これは、必須ステータスチェックのデフォルト動作です。 他のコラボレーターによるターゲットブランチ更新後に、head ブランチを最新の状態にする必要があるため、より多くのビルドが必要となるかもしれません。|\n```\n\n\\| **\\[Loose (寛容)]** |\n**[Require branches to be up to date before merging](マージ前にブランチの最新状態必須)** チェックボックスをオンに**しません**。 | ブランチは、マージ前にベース ブランチと同じ最新状態である必要は**ありません**。 | 他のコラボレーターがプルリクエストをマージした後にヘッドブランチを最新の状態にする必要がないため、必要なビルドの数が減少します。 ベースブランチと互換性のない変更がある場合、ブランチをマージするとステータスチェックが失敗する可能性があります。 |\n\\| **Disabled** |\n**[Require status checks to pass before merging](マージ前に状態チェック合格必須)** チェックボックスをオンに**しません**。 | ブランチのマージについての制限はない | 必須ステータスチェックが有効化されていない場合、base ブランチにあわせてアップデートされているかどうかに関わらず、コラボレーターはいつでもブランチをマージできます。 互換性のない変更の可能性が高まります。\n\nトラブルシューティング情報については、「[必須ステータスチェックのトラブルシューティング](/ja/pull-requests/collaborating-with-pull-requests/collaborating-on-repositories-with-code-quality-features/troubleshooting-required-status-checks)」を参照してください。\n\n### [Require conversation resolution before merging](マージ前に会話の解決必須)\n\npull request を保護されたブランチにマージする前に、関連するすべてのコメントを解決する必要があります。 これにより、マージ前にすべてのコメントが対処または確認されます。\n\n### [Require signed commits](署名済みコミット必須)\n\nコミット署名の必須化をブランチで有効にすると、共同作成者とボットは、署名されて検証されたコミットのみをブランチにプッシュできます。 詳しくは、「[コミット署名の検証について](/ja/authentication/managing-commit-signature-verification/about-commit-signature-verification)」をご覧ください。\n\n> \\[!NOTE]\n\n> * 警戒モード (コミットが常に署名される) を有効にした場合、GitHub によって [Partially verified](部分的に検証済み) と識別されたすべてのコミットは、署名済みコミットが必須であるブランチで許可されます。 警戒モードの詳細については、「[すべてのコミットの検証ステータスを表示する](/ja/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits)」を参照してください。\n> * コラボレーターが未署名のコミットを、コミット署名必須のブランチにプッシュする場合、コラボレーターは検証済み署名を含めるためにコミットをリベースしてから、書き直したコミットをブランチにフォース プッシュする必要があります。\n\nコミットが署名および検証されている場合は、いつでもローカルコミットをブランチにプッシュできます。 Pull request を使用して、署名および検証されているコミットをブランチにマージすることもできます。 ただし、pull request 作成者でない限り、pull request をスカッシュして GitHub のブランチにマージすることはできません。pull request をローカルでスカッシュおよびマージできます。 詳しくは、「[プルリクエストをローカルでチェック アウトする](/ja/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally)」をご覧ください。\n\nマージ方法の詳細については、「[GitHubのマージ メソッドについて](/ja/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/about-merge-methods-on-github)」を参照してください。\n\n### 線形履歴を要求する\n\n直線状のコミット履歴を強制すると、コラボレータがブランチにマージコミットをプッシュすることを防げます。 つまり、保護されたブランチにマージされたプルリクエストは、squash マージまたはリベースマージを使用する必要があります。 厳格な直線状のコミット履歴は、チームが変更をより簡単に元に戻すために役立ちます。 マージ方法の詳細については、「[プルリクエストのマージについて](/ja/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/about-pull-request-merges)」を参照してください。\n\n直線状のコミット履歴をリクエストする前に、リポジトリで squash マージまたはリベースマージを許可する必要があります。 詳しくは、「[プルリクエストのマージ設定を行う](/ja/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges)」をご覧ください。\n\n### \\[Require merge queue]\\(マージ キュー必須)\n\nマージ キューを使用すると、pull request のマージをビジー ブランチに自動化し、互換性のない変更によってブランチが中断されないようにすることで、速度を向上できます。\n\nマージ キューは、 **\\[マージする前にブランチを最新の状態にする]** ブランチ保護と同じ利点を提供しますが、pull request の作成者が pull request ブランチを更新し、状態チェックが完了するのを待ってからマージを試みる必要はありません。\n\nマージ キューの使用は、多くの異なるユーザーから毎日比較的多数の pull request がマージされるブランチで特に便利です。\n\npull request が必要なすべてのブランチ保護チェックに合格すると、リポジトリへの書き込みアクセス権を持つユーザーは、その pull request をキューに追加できます。 マージ キューでは、pull request の変更がターゲット ブランチの最新バージョンとキュー内に既に存在する pull request に適用されたときに、それらが必要な状態チェックをすべて通過したことが保証されます。\n\nマージ キューでは、GitHub Actions または独自の CI プロバイダーを使用して、マージ キュー内の pull request に対して必要なチェックを実行できます。 詳しくは、「[GitHub Actions ドキュメント](/ja/actions)」をご覧ください。\n\nGitHub は、必要なすべての CI チェックに合格すると、ブランチ保護で構成されたマージ戦略に従って pull request をマージします。マージ キューの詳細については、「[マージキューの管理](/ja/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-merge-queue)」を参照してください。\n\n### マージ前に展開の成功が必要\n\nブランチをマージする前に、変更が特定の環境に正常にデプロイされる必要があるように設定できます。 たとえば、この規則を使用し、変更がステージング環境に正常にデプロイされた後で、変更を既定のブランチにマージされるようにすることができます。\n\n### ブランチをロック\n\nブランチをロックすると、ブランチは読み取り専用になり、ブランチに対してコミットを行えなくなります。 ロックされたブランチも削除できません。\n\n既定では、フォークされたリポジトリでは、アップストリーム リポジトリからの同期はサポートされていません。\n**\\[フォークの同期を許可する]** を有効にして、フォークのブランチへの他のコントリビューションを防ぎながら、アップストリーム リポジトリから変更をプルできます。\n\n### 上記の設定をバイパスすることを許可しない\n\n既定では、ブランチ保護ルールの制限は、リポジトリの管理者アクセス許可を持つユーザーまたはリポジトリでの \\[ブランチ保護をバイパスする] アクセス許可を持つカスタム役割には適用されません。\n\nこの設定を有効にして、管理者および \"ブランチ保護をバイパスする\" アクセス許可を持つロールにも、制限を適用できます。 詳しくは、「[組織のカスタムリポジトリロールの管理](/ja/enterprise-cloud@latest/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/managing-custom-repository-roles-for-an-organization)」をご覧ください。\n\n### \\[Restrict who can push to matching branches]\\(一致するブランチにプッシュできるユーザーを制限)\n\nパブリック リポジトリが GitHub Free 組織によって所有されているか、すべてのリポジトリが GitHub Team または GitHub Enterprise Cloud を使用する組織によって所有されている場合に、ブランチ制限を有効にできます。\n\nブランチ制限を有効にすると、権限を与えられたユーザ、チーム、またはアプリのみが保護されたブランチにプッシュできます。 保護されたブランチの設定で、保護されたブランチへのプッシュアクセスを使用して、ユーザ、チーム、またはアプリを表示および編集できます。 状態チェックが必須である場合は、必須チェックに失敗すると、保護されたブランチにプッシュするアクセス許可を持つユーザー、チーム、アプリでも、ブランチにマージすることはできません。 pull request が必須な場合は、保護されたブランチにプッシュするアクセス許可を持つユーザー、チーム、アプリでも pull request を作成する必要があります。\n\n必要に応じて、規則と一致するブランチの作成にも同じ制限を適用できます。 たとえば、`release` という語を含むブランチに特定のチームのみがプッシュすることを許可する規則を作成した場合は、そのチームのメンバーしか `release` という語を含む新しいブランチを作成できません。\n\n保護されたブランチに対するプッシュ アクセスを付与したり、一致するブランチを作成するアクセス許可を付与したりできるのは、リポジトリへの書き込みアクセスを持つ、ユーザー、チーム、またはインストール済みの GitHub Apps のみです。 リポジトリへの管理者権限を持つユーザーとアプリは、保護されたブランチへのプッシュや一致するブランチの作成をいつでも行うことができます。\n\n### フォースプッシュを許可\n\n既定では、GitHub はすべての保護されたブランチでフォース プッシュを禁止します。 保護されたブランチへのフォース プッシュを有効にするとき、フォース プッシュを行うことができる 2 つのグループのいずれかを選択できます。\n\n1. リポジトリに対して少なくとも書き込みアクセス許可を持つすべてのユーザー (管理者権限を持つユーザーを含む) が、ブランチにフォース プッシュできるようにします。\n2. 特定のユーザーまたはチームのみがブランチにフォース プッシュできるようにします。\n\n誰かがブランチにフォース プッシュした場合、そのフォース プッシュは、他のコラボレーターが作業のベースにしたコミットが、ブランチの履歴から削除されることを意味する可能性があります。 ユーザーが競合をマージしたり pull request を破損させたりした可能性があります。 フォース プッシュは、ブランチを削除したり、pull request で承認されていないコミットをブランチで指し示したりするために、使うこともできます。\n\nフォースプッシュを有効化しても、他のブランチ保護ルールは上書きされません。 たとえば、ブランチに直線状のコミット履歴が必要な場合、そのブランチにマージコミットをフォースプッシュすることはできません。\n\n### [Allow deletions](削除を許可)\n\nデフォルトでは、保護されたブランチは削除できません。 保護されたブランチの削除を有効にすると、少なくともリポジトリへの書き込み権限を持つユーザは、ブランチを削除できます。\n\n> \\[!NOTE]\n> ブランチがロックされていると、削除するためのアクセス許可がある場合でも、ブランチを削除することはできません。"}