保護されたブランチについて

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

ブランチ保護ルールを作成することにより、コラボレータがリポジトリ内のブランチに変更をプッシュする前に、特定のワークフローまたは要件を適用できます。これには、プルリクエストのブランチへのマージが含まれます。

デフォルト設定では、各ブランチ保護ルールは、一致するブランチへのフォースプッシュを無効にし、一致するブランチが削除されないようにします。 必要に応じて、これらの制限を無効にし、追加のブランチ保護設定を有効にすることができます。

既定では、ブランチ保護ルールの制限は、リポジトリの管理者アクセス許可持つユーザーまたは "ブランチ保護をバイパスする" アクセス許可を持つカスタム ロールには適用されません。 必要に応じて、管理者および "ブランチ保護をバイパスする" アクセス許可を持つロールにも、制限を適用できます。 詳細については、「Organizationのカスタムリポジトリロールの管理」を参照してください。

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

すべてのマージの要件が満たされたときに、自動的にマージされるようにPull Requestを設定できます。 詳しくは、「プルリクエストを自動的にマージする」を参照してください。

ブランチ保護設定について

ブランチ保護ルールごとに、次の設定を有効にするか無効にするかを選択できます。

• [Require pull request reviews before merging](マージ前に pull request レビュー必須)
• マージ前にステータスチェック必須
• [Require conversation resolution before merging](マージ前に会話の解決必須)
• [Require signed commits](署名済みコミット必須)
• [Require linear history](直線状の履歴必須)
• マージ キュー必須
• マージの前にデプロイが成功する必要がある
• ブランチをロックする - 上の設定のバイパスを許可しない
• [Restrict who can push to matching branches](一致するブランチにプッシュできるユーザーを制限)
• [Allow force pushes](フォース プッシュを許可)
• [Allow deletions](削除を許可)

ブランチ保護を設定する方法について詳しくは、「ブランチ保護ルールを管理する」をご覧ください。

マージ前に Pull Request レビュー必須

リポジトリ管理者または "リポジトリ ルールの編集" アクセス許可を持つカスタム ロールは、保護されたブランチに他のユーザーがすべての pull request をマージする前に、特定の数の承認レビューがそれらの pull request に届くことを必須にすることができます。 リポジトリに書き込み権限を持っている人か、指定されたコードオーナーからの承認レビューを必須とすることができます。

必須レビューを有効にした場合、コラボレータは、書き込み権限を持つ必要な人数のレビュー担当者により承認されたプルリクエストからしか、保護されたブランチに変更をプッシュできなくなります。

管理者権限を持つユーザーがレビューで Request changes オプションを選択した場合、pull request をマージするためには、そのユーザーがその pull request を承認する必要があります。 プルリクエストへの変更をリクエストしたレビュー担当者の手が空いていない場合、そのリポジトリに書き込み権限を持つ人が、ブロックしているレビューを却下できます。

すべての必須のレビュー担当者がPull Requestを承認した後でも、同じコミットを指すヘッドブランチを持つ、保留中もしくは拒否されたレビューを持つオープンなPull Requestが他にある場合、コラボレータはそのPull Requestをマージできません。 まず、他のPull Request上のブロックしているレビューを、書き込み権限を持つ誰かが承認もしくは却下しなければなりません。

コラボレータが保留中または拒否されたレビューのプルリクエストを保護されたブランチにマージしようとすると、コラボレータにエラーメッセージが届きます。

remote: error: GH006: Protected branch update failed for refs/heads/main.
remote: error: Changes have been requested.

必要に応じて、pull request の差分に影響するコミットがプッシュされたときに、古い pull request の承認を無視することを選べます。 GitHub によって、pull request が承認された時点での差分の状態が記録されます。 この状態は、レビュー担当者が承認した一連の変更を表します。 差分がこの状態から (たとえば、共同作成者が pull request ブランチに新しい変更をプッシュしたか、 [ブランチを更新] をクリックしたため、または関連する pull request がターゲット ブランチにマージされたために) 変更された場合、レビューの承認は古いものとして無視され、誰かが作業をもう一度承認するまで pull request をマージすることはできません。 ベース ブランチについて詳しくは、「pull requests について」をご覧ください。

必要に応じて、プルリクエストレビューを却下する権限を、特定の人物またはチームに限定できます。 詳しくは、「プルリクエストレビューの却下」を参照してください。

必要に応じて、コードオーナー'からのレビューを必須にすることもできます。 この場合、コードオーナーのコードに影響するプルリクエストは、保護されたブランチにプルリクエストをマージする前に、そのコードオーナーから承認される必要があります。

必要に応じて、最新のレビュー可能なプッシュを、それをプッシュしたユーザー以外のユーザーが承認する必要があることを、要求できます。 これは、少なくとももう 1 人の許可されたレビュー担当者が変更を承認済みであることを意味します。 たとえば、"最後のレビュー担当者" は、最新の一連の変更に、他のレビューからのフィードバックが組み込まれていて、未レビューの新しいコンテンツが追加されていないことを確認できます。

多くのレビューを必要とする複雑な pull request の場合、妥協策として、最後にプッシュしたユーザー以外のユーザーによる承認を必須にすると、すべての古いレビューを無視する必要がなくなります。このオプションを使うと、"古い" レビューは無視されず、最新の変更を行ったユーザー以外のユーザーがそれを承認している限り、pull request は承認済みのままになります。 pull request を既にレビューしているユーザーは、最後のプッシュの後でもう一度承認して、この要件を満たすことができます。 pull request が "ハイジャックされる" (承認された pull request に未承認のコンテンツが追加される) 懸念がある場合は、古いレビューを無視する方が安全です。

マージ前にステータスチェック必須

必須ステータスチェックにより、コラボレータが保護されたブランチに変更を加える前に、すべての必須 CI テストにパスしていることが保証されます。 詳細は「保護されたブランチを設定する」および「必須ステータスチェックを有効にする」を参照してください。 詳しくは、「ステータスチェックについて」を参照してください。

コミット状態 API を使うと、外部サービスがコミットに適切な状態のマークを付けることを許可できます。 詳しくは、REST API ドキュメントの「コミットのステータスについて」をご覧ください。

ステータスチェック必須を有効にすると、すべてのステータスチェック必須がパスしないと、コラボレータは保護されたブランチにマージできません。 必須ステータスチェックをパスしたら、コミットを別のブランチにプッシュしてから、マージするか、保護されたブランチに直接プッシュする必要があります。

リポジトリへの書き込み権限があるユーザーまたは統合は、リポジトリのステータス チェックを任意の状態に設定できますが、場合によっては特定の GitHub App のステータス チェックのみを受け入れる必要があります。 必須状態チェックを追加するとき、このチェックを最近設定したアプリを、状態更新が想定されるソースとして選べます。 状態が他のユーザーまたは統合によって設定されている場合、マージは許可されません。 any source を選択した場合は、マージ ボックスに一覧表示されている各状態の作成者を引き続き手動で確認することができます。

必須ステータスチェックのタイプは、[loose] (寛容)、[strict] (厳格) のいずれかに設定できます。 選択した必須ステータスチェックのタイプにより、マージする前にブランチをベースブランチとともに最新にする必要があるかどうかが決まります。

必須ステータスチェックのタイプ	設定	マージの要件	考慮事項
Strict	Require branches to be up to date before merging チェックボックスをオンにします。	ブランチは、マージ前にベース ブランチと同じ最新状態である必要があります。	これは、必須ステータスチェックのデフォルト動作です。 他のコラボレーターがターゲット ブランチを更新したら、head ブランチを最新の状態にする必要があるため、追加のビルドが必要になる場合があります。
Loose	Require branches to be up to date before merging チェックボックスをオンにしません。	ブランチは、マージ前にベース ブランチと同じ最新状態である必要はありません。	他のコラボレーターがプルリクエストをマージした後に head ブランチをアップデートする必要はないことから、必要となるビルドは少なくなります。 base ブランチと競合する変更がある場合、ブランチをマージした後のステータスチェックは失敗する可能性があります。
Disabled	Require status checks to pass before merging チェックボックスをオンにしません。	ブランチのマージについての制限はない	必須ステータスチェックが有効化されていない場合、base ブランチにあわせてアップデートされているかどうかに関わらず、コラボレーターはいつでもブランチをマージできます。 このことで、変更の競合が発生する可能性が高まります。

トラブルシューティング情報については、「必須ステータスチェックのトラブルシューティング」をご覧ください。

Require conversation resolution before merging

pull request を保護されたブランチにマージする前に、関連するすべてのコメントを解決する必要があります。 これにより、マージ前にすべてのコメントが対処または確認されます。

署名済みコミットの必須化

コミット署名の必須化をブランチで有効にすると、共同作成者とボットは、署名されて検証されたコミットのみをブランチにプッシュできます。 詳しくは、「コミット署名の検証について」を参照してください。

コミットが署名および検証されている場合は、いつでもローカルコミットをブランチにプッシュできます。 GitHub の pull request を使用して、署名および検証されているコミットをブランチにマージすることもできます。 ただし、pull request の作者でない限り、pull request をスカッシュして GitHub のブランチにマージすることはできません。pull request をローカルでスカッシュおよびマージできます。 詳しくは、「プルリクエストをローカルでチェック アウトする」を参照してください。

マージ方法について詳しくは、「GitHub上のマージ方法について」をご覧ください。

直線状の履歴必須

直線状のコミット履歴を強制すると、コラボレータがブランチにマージコミットをプッシュすることを防げます。 つまり、保護されたブランチにマージされたプルリクエストは、squash マージまたはリベースマージを使用する必要があります。 厳格な直線状のコミット履歴は、Teamが変更をより簡単にたどるために役立ちます。 マージ方法について詳しくは、「プルリクエストのマージについて」をご覧ください。

直線状のコミット履歴をリクエストする前に、リポジトリで squash マージまたはリベースマージを許可する必要があります。 詳しくは、「プルリクエストマージを設定する」を参照してください。

[Require merge queue](マージ キュー必須)

マージ キューを使用すると、必要なすべてのブランチ保護チェックに合格することを保証しつつ、pull request がビジー状態のターゲット ブランチにマージされる速度を上げることができます。

pull request が必要なすべてのブランチ保護チェックに合格すると、リポジトリへの書き込みアクセス権を持つユーザーは、その pull request をマージ キューに追加できます。

マージ キューでは、GitHub Actions を使用できます。 詳しくは、「GitHub Actionsのドキュメント」を参照してください。

GitHub は、必要なすべての CI チェックに合格すると、ブランチ保護で構成されたマージ戦略に従って pull request をマージします。 マージ キューについては、「マージキューの管理」を参照してください。

Require deployments to succeed before merging

ブランチをマージする前に、変更が特定の環境に正常にデプロイされる必要があるように設定できます。 たとえば、この規則を使用し、変更がステージング環境に正常にデプロイされた後で、変更を既定のブランチにマージされるようにすることができます。

ブランチをロックする

ブランチをロックすると、ブランチに対してコミットを行えなくなります。 既定では、フォークされたリポジトリでは、アップストリーム リポジトリからの同期はサポートされていません。 [フォークの同期を許可する] を有効にして、フォークのブランチへの他のコントリビューションを防ぎながら、アップストリーム リポジトリから変更をプルできます。

上の設定のバイパスを許可しない

既定では、ブランチ保護ルールの制限は、リポジトリの管理者アクセス許可持つユーザーまたはリポジトリでの "ブランチ保護をバイパスする" アクセス許可を持つカスタム ロールには適用されません。

この設定を有効にして、管理者および "ブランチ保護をバイパスする" アクセス許可を持つロールにも、制限を適用できます。 詳細については、「Organizationのカスタムリポジトリロールの管理」を参照してください。

一致するブランチにプッシュできるユーザを制限

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

ブランチ制限を有効にすると、権限を与えられたユーザ、チーム、またはアプリのみが保護されたブランチにプッシュできます。 保護されたブランチの設定で、保護されたブランチへのプッシュアクセスを使用して、ユーザ、チーム、またはアプリを表示および編集できます。 状態チェックが必須である場合は、必須チェックに失敗すると、保護されたブランチにプッシュするアクセス許可を持つユーザー、チーム、アプリでも、ブランチにマージすることはできません。 pull request が必須な場合は、保護されたブランチにプッシュするアクセス許可を持つユーザー、チーム、アプリでも pull request を作成する必要があります。

必要に応じて、規則と一致するブランチの作成に同じ制限を適用できます。 たとえば、release という語を含むブランチに特定のチームのみがプッシュすることを許可する規則を作成した場合は、そのチームのメンバーしか release という語を含む新しいブランチを作成できません。

保護されたブランチに対するプッシュ アクセスを付与したり、一致するブランチを作成するアクセス許可を付与したりできるのは、リポジトリへの書き込みアクセスを持つ、ユーザー、チーム、またはインストール済みの GitHub Apps のみです。 リポジトリへの管理者権限を持つユーザーとアプリは、保護されたブランチへのプッシュや一致するブランチの作成をいつでも行うことができます。

フォースプッシュを許可

デフォルトでは、GitHub はすべての保護されたブランチでフォースプッシュをブロックします。 保護されたブランチへのフォース プッシュを有効にするとき、フォース プッシュを行うことができる 2 つのグループのいずれかを選択できます。

1. リポジトリに対して少なくとも書き込みアクセス許可を持つすべてのユーザー (管理者権限を持つユーザーを含む) が、ブランチにフォース プッシュできるようにします。
2. 特定のユーザーまたはチームのみがブランチにフォース プッシュできるようにします。

誰かがブランチに強制的にプッシュした場合、その強制的なプッシュは、他のコラボレーターが作業のベースにしたコミットが、ブランチの履歴から削除されることを意味する可能性があります。 ユーザーが競合をマージしたり pull request を破損させたりした可能性があります。 強制プッシュは、ブランチを削除したり、pull request で承認されていないコミットをブランチで指し示したりするために、使うこともできます。

フォースプッシュを有効化しても、他のブランチ保護ルールは上書きされません。 たとえば、ブランチに直線状のコミット履歴が必要な場合、そのブランチにマージコミットをフォースプッシュすることはできません。

削除を許可

デフォルトでは、保護されたブランチは削除できません。 保護されたブランチの削除を有効にすると、少なくともリポジトリへの書き込み権限を持つユーザは、ブランチを削除できます。