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

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

ブランチ保護ルールを作成することにより、コラボレータがリポジトリ内のブランチに変更をプッシュする前に、特定のワークフローまたは要件を適用できます。これには、プルリクエストのブランチへのマージが含まれます。 アクターをバイパス リストに追加できるのは、リポジトリが組織に属している場合のみです。

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

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

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

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

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

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

• [Require pull request reviews before merging](マージ前に pull request レビュー必須)
• マージ前にステータスチェック必須
• [Require conversation resolution before merging](#require-conversation-resolution-before-merging)
• [Require signed commits](#require-signed-commits)
• 直線状の履歴必須
• マージの前にデプロイが成功する必要がある
• ブランチをロックする
• 上の設定のバイパスを許可しない
• [Restrict who can push to matching branches](#restrict-who-can-push-to-matching-branches)
• [Allow force pushes](フォース プッシュを許可)
• [Allow deletions](#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 が承認された時点での diff の状態を記録します。 この状態は、レビュー担当者が承認した一連の変更を表します。 差分がこの状態から (たとえば、共同作成者が 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 を保護されたブランチにマージする前に、関連するすべてのコメントを解決する必要があります。 これにより、マージ前にすべてのコメントが対処または確認されます。

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

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

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

直線状の履歴必須

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

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

Require deployments to succeed before merging

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

ブランチをロックする

ブランチをロックすると、ブランチは読み取り専用になり、ブランチに対してコミットを行えなくなります。 ロックされたブランチも削除できません。

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

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

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

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

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

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

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

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

フォースプッシュを許可

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

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

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

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

サイト管理者がリポジトリ内のすべてのブランチへのフォース プッシュをブロックしている場合、保護されたブランチのフォース プッシュを有効にすることはできません。 詳しくは、「Enterprise でリポジトリ管理ポリシーを適用する」を参照してください。

サイト管理者がデフォルトブランチへのフォースプッシュのみをブロックしている場合、他の保護されたブランチに対してフォースプッシュを有効にできます。

削除を許可

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