Featured image of post GitHubのブランチ保護のルールについて調べたときのメモ

GitHubのブランチ保護のルールについて調べたときのメモ

これはなに Link to this heading

GitHubで設定できるブランチ保護のルールについて調べたときのメモ。

前提 Link to this heading

ここでは、Target branchesにmainを指定した場合の、各設定の意味を説明する。 そのため、本稿のmainは任意のブランチ名に変更できる。

ルールセット Link to this heading

Restrict creations(作成の制限) Link to this heading

Only allow users with bypass permission to create matching refs.

この設定を有効にすると、バイパス権限を持つユーザー以外の、mainブランチ/タグの作成を禁止できる。

通常mainブランチは最初に作成されるため、mainブランチの作成を禁止することはないだろう。main-*のようなパターンを指定すると、意味のある設定になる。

Restrict updates(更新の制限) Link to this heading

Only allow users with bypass permission to update matching refs.

この設定を有効にすると、バイパス権限を持つユーザー以外の、mainブランチ/タグへのプッシュを禁止できる。バイパス権限を持つユーザーは、Bypass listで指定する。

たとえば、もしBypass listに誰も指定しなければ、mainブランチ/タグへのプッシュをすべて禁止にできる。

別の例として、リポジトリのadmin権限を自分しか持っていない場合、ルールのBypass listにRepository adminを指定してこの設定を有効にする。すると、自分だけがmainブランチを更新できるようになる。

Restrict deletions(削除の制限) Link to this heading

Only allow users with bypass permissions to delete matching refs.

この設定を有効にすると、バイパス権限を持つユーザー以外の、mainブランチ/タグの削除を禁止できる。

この設定はデフォルトで有効になっている。誤ったmainブランチの削除を防ぐためにも、この設定は有効にしておくべきである。

Require linear history(直線状の履歴必須) Link to this heading

Prevent merge commits from being pushed to matching refs.

この設定を有効にすると、mainブランチ/タグへのマージコミットを禁止できる。 つまり、mainブランチ/タグへマージする際に、Squash and mergeあるいはRebase and mergeの使用を強制できる。

この設定はチームの方針による。個人的には、この設定はmainブランチには使わず、feature/*ブランチなどに使う。

Require deployments to succeed(デプロイ成功必須) Link to this heading

Choose which environments must be successfully deployed to before refs can be pushed into a ref that matches this rule.

この設定を有効にすると、mainブランチ/タグへのプッシュを許可する前に、指定した環境へのデプロイ成功を必須にできる。

mainブランチをどこかにデプロイしているなら、この設定を有効にしておくとよい。

Require signed commits(署名済みコミット必須) Link to this heading

Commits pushed to matching refs must have verified signatures.

この設定を有効にすると、mainブランチ/タグへのプッシュを許可する前に、署名済みコミットを要求できる。

自分が署名済みコミットを使っているなら、この設定を有効にしておくと、なりすましなどを防げる。

Require a pull request before merging(マージ前のプルリクエストの必須) Link to this heading

Require all commits be made to a non-target branch and submitted via a pull request before they can be merged.

この設定を有効にすると、mainブランチ/タグへのプッシュを許可する前に、プルリクエストを要求できる。

複数人で開発する場合、mainブランチへの直接のプッシュを禁止できるため、この設定は有効にしておくべきである。

この設定には追加設定がある。

Required approvals Link to this heading

The number of approving reviews that are required before a pull request can be merged.

この設定は、プルリクエストをマージするために必要な承認レビューの数を指定できる。 この値を1以上にすると、たとえ自分がプルリクエストを作成していても、他の人にレビューしてもらう必要がある。

この設定を1以上にすると、リポジトリの管理者ですらマージの際にレビューを受けなければならなくなってしまう。しかも、自分自身をレビュワーにはできない。 そのため、リポジトリを自分1人しか更新しないなら、この設定は0にしておく。

Dismiss stale pull request approvals when new commits are pushed Link to this heading

New, reviewable commits pushed will dismiss previous pull request review approvals.

この設定を有効にすると、新しいコミットがプッシュされたときに、古いプルリクエストの承認レビューが無効になる。

大抵の場合は、この設定を有効にしておくとよい。

Require review from Code Owners Link to this heading

Require an approving review in pull requests that modify files that have a designated code owner.

この設定を有効にすると、指定したコードオーナーによるレビューを強制できる。 コードオーナーは、CODEOWNERSファイルで指定する。

コードオーナーについて - GitHub Docs's image

コードオーナーについて - GitHub Docs

CODEOWNERS ファイルを使い、リポジトリ中のコードに対して責任を負う個人あるいは Team を指定できます。

docs.github.com

CODEOWNERSファイルを作成して自分を指定し、この設定を有効にしておくと、自分はプルリクエストを承認無しでマージでき、他の人にはコードオーナー(すなわち自分)によるレビューを強制できる。 そのため、他人のプルリクエストを受け付けるけれど、自分のプルリクエストは自分でマージしたい場合に便利である。

Require approval of the most recent reviewable push Link to this heading

Whether the most recent reviewable push must be approved by someone other than the person who pushed it.

この設定を有効にすると、プルリクエストをマージする前に、最後にプッシュした人以外の誰かによる承認を強制できる。つまり、自己承認を防げる。

大規模な開発の場合は有効にすると良さそう。

Require conversation resolution before merging Link to this heading

All conversations on code must be resolved before a pull request can be merged.

この設定を有効にすると、プルリクエストをマージする前に、すべてのコードに関する会話(コメント)を解決する必要がある。よって、プルリクエストへのコメントの見逃しを防げる。

この設定は、プルリクエストの品質を向上させるため、有効にしておくとよい。

Require status checks to pass(ステータスチェックのパスの強制) Link to this heading

Choose which status checks must pass before the ref is updated. When enabled, commits must first be pushed to another ref where the checks pass.

この設定を有効にすると、mainブランチ/タグへのプッシュを許可する前に、指定したステータスチェックのパスを強制できる。 つまり、必須CI/CDの通過を要求できる。

Status checks that are requiredに、必須にしたいステータスチェックを追加する。

この設定には追加設定がある。

Require branches to be up to date before merging Link to this heading

Whether pull requests targeting a matching branch must be tested with the latest code. This setting will not take effect unless at least one status check is enabled.

この設定を有効にすると、プルリクエストに対して、最新のコードによるテストを要求できる。

大抵の場合は、この設定を有効にしておくとよい。

Do not require status checks on creation Link to this heading

Allow repositories and branches to be created if a check would otherwise prohibit it.

この設定を有効にすると、ブランチやリポジトリの作成時には、ステータスチェックを必須としなくなる。

ステータスチェックを通せないくらいの初期段階では有効にしてもよいだろう。

Block force pushes(強制プッシュのブロック) Link to this heading

Prevent users with push access from force pushing to refs.

この設定を有効にすると、mainブランチ/タグへの強制プッシュを禁止できる。

この設定はデフォルトで有効になっている。誤ったmainブランチの強制プッシュを防ぐためにも、この設定は有効にしておくべきである。

Require code scanning results(コードスキャンの強制) Link to this heading

Choose which tools must provide code scanning results before the reference is updated. When configured, code scanning must be enabled and have results for both the commit and the reference being updated.

この設定を有効にすると、mainブランチ/タグへのプッシュを許可する前に、指定したコードスキャン結果の提供を強制できる。

Required tools and alert thresholdsに、必須にしたいコードスキャンツールを追加する。

コードスキャンを利用しているなら。この設定を有効にしておくとよさそう。

参考文献・URL Link to this heading

ルールセットで使用できるルール - GitHub Docs's image

ルールセットで使用できるルール - GitHub Docs

リポジトリ内の特定のブランチとタグを保護するためにルールセットに追加できるルールについて説明します。

docs.github.com
リポジトリ管理者はapproveなしでマージできるようにしようとしたら少しハマった話 - Qiita's image

リポジトリ管理者はapproveなしでマージできるようにしようとしたら少しハマった話 - Qiita

はじめに個人開発用のリポジトリを作成し、Branch protection ruleを設定していた時の話です。設定項目が間違っており、意図した挙動になっていなかったのを解消しました。やりたかっ…

qiita.com
Licensed under CC BY-NC-SA 4.0
最終更新 9月 29, 2024
Hugo で構築されています。
テーマ StackJimmy によって設計されています。