🧰

Check! GitHub Branch protection rulesの機能一覧

2023/08/04に公開

GitHub

tech

Prologue

こんにちは、@dz_ こと、岩永かづみです。

GitHubリポジトリのBranch protection rulesは、指定したブランチを保護するためのルールを設定できる機能です。

たとえば、以下のような条件を設けられます。

force pushを禁止する
ブランチの削除を禁止する
直接のマージを禁止し、プルリクエストを必須にする
プルリクエストをマージする際に、承認（approval）を必須にする、など

ここでは、それぞれの機能を簡単に確認できるようにまとめます。

Branch protection rulesの一覧

Branch protection rulesは、個人アカウント配下のリポジトリと、Organization配下のリポジトリで一部の項目が異なります。表にまとめました。

Protect matching branches

パターンに一致するブランチを保護するルールの一覧です。

項目	小項目	説明	個人アカウント配下	Organization配下
`Require a pull request before merging`		マージする前に、プルリクエストを要求する	○	○
	`Require approvals`	プルリクエストにおいて、承認（approval）を要求する	○	○
	`Dismiss stale pull request approvals when new commits are pushed`	新しいコミットがプッシュされたときに古い承認を取り消す	○	○
	`Require review from Code Owners`	Code Ownersによるレビューを要求する	○	○
	`Restrict who can dismiss pull request reviews`	プルリクエストのレビュー（変更を要求するレビュアによる承認を必要とする状態）を却下できる人を制限する	×	○
	`Allow specified actors to bypass required pull requests`	指定したユーザーに対し、プルリクエストの要求を課さない	×	○
	`Require approval of the most recent reviewable push`	~~Approvalを得た後にプッシュされた変更がある場合は、approvalを要求する~~ 最後のレビュー可能なpushを行った人以外からのapprovalを要求する	○	○
`Require status checks to pass before merging`		マージする前に、status checkをクリアしていることを要求する	○	○
	`Require branches to be up to date before merging`	マージする前に、作業ブランチが最新（マージ先のブランチの変更が取り込まれている）であることを要求する	○	○
`Require conversation resolution before merging`		マージする前に、プルリクエストのconversation（コメント）が解決されていることを要求する	○	○
`Require signed commits`		署名付きのコミットを要求する	○	○
`Require linear history`		履歴の分岐を許さない	○	○
`Require merge queue`		マージキューを要求する	×	○
`Require deployments to succeed before merging`		マージする前に、deploymentsが成功することを要求する	○	○
`Lock branch`		ブランチをロックする（プッシュを禁止する）	○	○
`Do not allow bypassing the above settings`		（管理者とカスタムロールで"bypass branch protections"の権限を持つユーザーに対し）上記の設定のbypassを許さない	○	○
`Restrict who can push to matching branches`		対象のブランチに対し、pushできる人を制限する	×	○
	`Restrict pushes that create matching branches`	命名規則が合致するブランチの作成ができる人を制限する	×	○

Rules applied to everyone including administrators

administrators（管理者）に対しても適用されるルールの一覧です。

項目	説明	個人アカウント配下	Organization配下
Allow force pushes	force pushを許す	○	○
Allow deletions	ブランチの削除を許す	○	○

それぞれの画面キャプチャ

個人アカウント配下のリポジトリのBranch protection rules

Organization配下のリポジトリのBranch protection rules

設定項目の短い解説

分かりにくい設定項目について、簡単に解説します。

（※ この記事は、GitHub dockyardコミュニティ竣工イベント！のセッションで紹介したいがスライドにまとめるのが難しい内容について、書き起こしたものです。この章も完成させたいのですが、まずはセッション資料作成を優先して、追って更新します😂）

Restrict who can dismiss pull request reviews

まず、プルリクエストは、承認（approve）ではなく「Require changes（変更の要求）」を指定することができ、コードの修正や改良を促すことができます。

プルリクエストの「Request changes」

この「change requested」の状態は誰でもdismiss（無視）できる（※）ので、変更の要求を無視してマージできてしまいます。

プルリクエストの「change requested」をdismissできる

そこで、Branch protection rulesの「Restrict who can dismiss pull request reviews」を有効化しておくことで、dismissできないように制限できます。設定の直接的な意味合いは「dismissできる人を制限する」で、誰も指定しない場合は誰もがdismissができない状態になります。ここにユーザー、チーム、GitHub Appsを指定すると、対象のユーザーはdismissできるように制御できます。

Branch protection rulesの「Restrict who can dismiss pull request reviews」を有効化し、ユーザーを指定した状態

プルリクエストの画面ではこのようにdismissの選択肢が表示されなくなります。

プルリクエストの「change requested」のdismissができない場合のUI

これにより、レビュアによる変更の要求に対し、対応を行うか、再レビューを依頼するフローを自然に組み込めます。

なお、この設定を有効にするだけではApprovalの要求は行われず、レビューされない状態でもマージできてしまうので、「Require approvals」も併せて有効にしておくことでレビューを作業フローに組み込みやすくなるでしょう。

Require status checks to pass before merging

status checkに関する解説を書きたい

Require linear history

linear historyの解説を書きたい

Epilogue

Branch protection rulesが個人アカウント配下とOrganization配下で項目が異なることをつい先日知りまして、思わずまとめました。業務でワークショップやアドバイザリを行うときは、Organization配下のリポジトリを扱うことが多いので、気づいていなかったのでした。

まとめられてすっきり！