忙しくてGitHubブランチ保護を後回しにしているあなた向けの記事。

※ Organization アカウント
※ GitHub Team プラン
※ 2023.08.14 現在の設定および並び順

上からみていく

Branch name pattern

mainやdevelop とか。
ワイルドカード使えます（feature/*だとfeature/hoge01, feature/fuga01）

Require a pull request before merging

PR経由でしかマージさせない

（うんうん、必須だ）

Require approvals

PR前に承認を必要とさせる。必要承認人数も選択できる

（一応いれていおこう）

Dismiss stale pull request approvals when new commits are pushed

PR（マージじゃなくて承認）後に、新しいコミットが来たら、承認を却下させる。

（なるほど確かにもう一度チェックが必要だ）

Require review from Code Owners

PR時にコードオーナーを自動でレビュアーとして設定する

（いやいや事前にまずはコードオーナーについて知っておく必要があるね...）

Restrict who can dismiss pull request reviews

PRレビューを却下できる人を設定する。

（なるほど！レビューでRequest Changesになり、その後なるはやで修正したが、レビュアーさんが体調不良でずっと休みになってしまった！でも明日リリースしないといけない時はレビューの却下が必要だ！。）

使用ケース

Allow specified actors to bypass required pull requests

特定の人やチームに「ブランチ保護ルール」を適用させないようにする

（いや、そんな特別扱いすべき人達はおらず...）

Require approval of the most recent reviewable push

レビューが必要なプッシュが発生した場合、「プッシュ者以外（他者）」に承認者を求める

（うーん、まぁそうかもしれないが）

Require status checks to pass before merging

PRマージ前にコミットステータスチェック合格が必要とする

（CIテスト合格は必要だよな！。深堀して理解したい方はこちら（コミットのステータス）

Require branches to be up to date before merging

作業ブランチは、マージ先の最新コミットが取り込まれている状態を必要とする

（確かに最新状態のコードでテスト合格しないと意味がないか！）

Require conversation resolution before merging

マージ前にConversationがの解決を必要とする

（Resolveボタンを押せよってことか！）

Require signed commits

署名付きコミットを必要とします

（いや、そもそもコミット署名とか知らぬかった！ムズイ！）

Require linear history

直線状の履歴を必須とする。rebaseかsquashしてください

（なんと、マージコミットが含まれる事を禁止するそうです😢厳しい〜）

Require deployments to succeed before merging

マージ前に「特定の環境へのデプロイの成功」を必要とします

（「デプロイメントの成功」ってどこで判断している？)

継続的インテグレーションについて| GitHub
継続的デプロイについて | GitHub
- 今回は↑こっち

そんでもって少し気になったのですが「GitHub ActionsにおいてCIとCDをそれぞれどこで自動で判別している？」について恐らく、environmentの記述があるとデプロイメントのセクションと判断されるっぽいような...
違ったらコメントくださいませ。

jobs:
  deployment:
    runs-on: ubuntu-latest
    environment: production

Lock branch

ブランチをロックする

（急にシンプルなのが出てきたな。そもそもPRによるマージもさせない？とかメンテナンスとかで利用するのかな。ここ後ほど説明更新が必要だ...）

Do not allow bypassing the above settings

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

（「リポジトリ管理者やバイパス権限保持者でも許可しないよ」か...強い）

Restrict who can push to matching branches

ブランチにプッシュできる人を制限します。

（ここにきて査定が入ります）

Restrict pushes that create matching branches

Only people, teams, or apps allowed to push will be abl

そして、そのチームメンバーのみ設定対象のブランチ名の文字を含む新しいブランチを作成できません。

（確かにそうだわ、確かに似たようなブランチ名を勝手に作成されちゃ困りますね）

Allow force pushes

フォースプッシュを許可する

（最後のブロック、ここからは、許可したい場合にチェックを入れるのか。うんうん）

Allow deletions

ブランチ削除を許可する

（お疲れ様でした）

総括

長かった。制限する手法があの手この手であるので理解するのに時間がかかりますね。
そしてひとつ言えることは設定箇所全部が急所でした。

参考記事

保護されたブランチについて | GitHub Docs
New Branch Protections: Last Pusher and Locked Branch
GitHub の Repository Rules を試してみる | Zenn
- ものすごく丁寧に解説および実験してくれてます。🥺
GitHub Enterprise でブランチに push や merge できるユーザーを制限したい