Skip to main content

このバージョンの GitHub Enterprise はこの日付をもって終了となりました: 2023-01-18. 重大なセキュリティの問題に対してであっても、パッチリリースは作成されません。 パフォーマンスの向上、セキュリティの向上、新機能の向上を図るために、最新バージョンの GitHub Enterprise にアップグレードします。 アップグレードに関するヘルプについては、GitHub Enterprise サポートにお問い合わせく� さい

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

この記事では、次の� �目が扱われます。

重要なブランチを保護するには、ブランチ保護ルールを設定します。このルールは、コラボレータがブランチへのプッシュを削除または強制できるかどうかを定義し、ステータスチェックのパスや直線状のコミット履歴など、ブランチへのプッシュの要件を設定します。

保護されたブランチは、GitHub Free及びOrganizationのGitHub Freeのパブリックリポジトリ、GitHub Pro、GitHub Team、GitHub Enterprise Cloud、GitHub Enterprise Serverのパブリック及びプライベートリポジトリで利用できます。

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

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

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

既定では、ブランチ保護ルールの制限は、リポジトリの管理者アクセス許可を持つユーザーには適用されません。 必要に応じて、管理者を含めることもできます。

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

すべてのマージの要件が満たされたときに、自動的にマージされるようにPull Requestを設定できます。 詳細については、「pull request を自動的にマージする」を参照してく� さい。

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

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

ブランチ保護を設定する方法の詳細については、「ブランチ保護規則を管理する」を参照してく� さい。

マージ前に 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 について」を参照してく� さい。

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

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

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

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

ステータス チェック必� �を有効にする前に、コミット ステータス API を使うようにリポジトリを構成する必要があります。 詳しくは、REST API のドキュメントの「コミットのステータス」をご覧く� さい。

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

リポジトリへの書き込み権限があるユーザーまたは統合は、リポジトリのステータス チェックを任意の状態に設定できます。状態が他のユーザーまたは統合によって設定されている� �合、マージは許可されません。 [any source](任意のソース) を選択した� �合は、マージ ボックスに一覧表示されている各状態の作成者を引き続き手動で確認することができます。

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

必� �ステータスチェックのタイプ設定マージの要件考慮事� �
Strict[Require branches to be up to date before merging](マージ前にブランチの最新状態必� �) チェックボックスをオンにします。ブランチは、マージ前にベース ブランチと同じ最新状態である 必要がありますこれは、必� �ステータスチェックのデフォルト動作です。 他のコラボレーターが、保護された base ブランチにプルリクエストをマージした後に、あなたは 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 をローカルでマージできます。 詳しくは、「pull request をローカルでチェックアウトする」を参照してく� さい。

直線状の履歴必� �

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

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

[Require deployments to succeed before merging](マージ前にデプロイ成功必� �)

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

管理者を含める

既定では、保護されたブランチのルールは、リポジトリの管理者アクセス許可を持つユーザーには適用されません。 この設定を有効化すると、保護されたブランチのルールに管理者を含めることができます。

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

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

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

フォースプッシュを許可

既定では、GitHub Enterprise Server はすべての保護されたブランチでフォース プッシュをブロックします。 保護されたブランチのフォースプッシュを有効にすると、少なくともリポジトリへの書き込み権限を持つユーザは、管理者権限を持つブランチを含め、ブランチをフォースプッシュできます。 誰かがブランチにフォース プッシュした� �合、フォース プッシュによって、他のコラボレーターがそれに基づいて作業しているコミットを上書きする可能性があります。 ユーザーが競合をマージしたり pull request を� �損させたりした可能性があります。

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

サイト管理者がリポジトリ内のすべてのブランチへのフォース プッシュをブロックしている� �合、保護されたブランチのフォース プッシュを有効にすることはできません。 詳細については、「個人アカウントまたは組織が所有するリポジトリへのフォース プッシュをブロックする」を参照してく� さい。

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

削除を許可

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