そろそろ「GitHubブランチ保護」機能の急所のみ理解しておきたい。

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

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

# 上からみていく

## Branch name pattern

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

## Require a pull request before merging

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

（うんうん、必須だ）

### Require approvals

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

（一応いれていおこう）

### Dismiss stale pull request approvals when new commits are pushed

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

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

### Require review from Code Owners

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

（いやいや事前にまずは[コードオーナー](https://docs.github.com/ja/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners)について知っておく必要があるね...）

### Restrict who can dismiss pull request reviews

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

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

[使用ケース](https://blog.beachside.dev/entry/2022/03/02/193000)

### Allow specified actors to bypass required pull requests

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

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

### Require approval of the most recent reviewable push

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

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

## Require status checks to pass before merging

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

（CIテスト合格は必要だよな！。深堀して理解したい方は[こちら（コミットのステータス）](https://docs.github.com/ja/rest/commits/statuses?apiVersion=2022-11-28)

- [継続的インテグレーションについて| GitHub](https://docs.github.com/ja/actions/automating-builds-and-tests/about-continuous-integration)
    - ↑こっち
- [継続的デプロイについて | GitHub](https://docs.github.com/ja/actions/deployment/about-deployments/about-continuous-deployment)

## Require branches to be up to date before merging

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

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

## Require conversation resolution before merging

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

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/26033/b1329d9e-f390-5942-5885-4e0a684c6401.png)

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

## Require signed commits

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

（いや、そもそも[コミット署名](https://docs.github.com/ja/authentication/managing-commit-signature-verification/about-commit-signature-verification)とか知らぬかった！ムズイ！）

## Require linear history

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

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

## Require deployments to succeed before merging

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

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

- [継続的インテグレーションについて| GitHub](https://docs.github.com/ja/actions/automating-builds-and-tests/about-continuous-integration)
- [継続的デプロイについて | GitHub](https://docs.github.com/ja/actions/deployment/about-deployments/about-continuous-deployment)
    - 今回は↑こっち

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

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

## Lock branch

:::note warn
ブランチをロックする
:::

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

## Do not allow bypassing the above settings

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

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

## Restrict who can push to matching branches

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

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

### Restrict pushes that create matching branches
Only people, teams, or apps allowed to push will be abl

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

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

## Allow force pushes

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

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

## Allow deletions

:::note warn
ブランチ削除を許可する
:::

（お疲れ様でした）

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/26033/6935db56-ccfb-aec0-4f6a-b710aa8a2208.png)

## 総括

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

# 参考記事

- [保護されたブランチについて | GitHub Docs](https://docs.github.com/ja/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches)
- [New Branch Protections: Last Pusher and Locked Branch
](https://github.blog/changelog/2022-10-20-new-branch-protections-last-pusher-and-locked-branch/)
- [GitHub の Repository Rules を試してみる | Zenn](https://zenn.dev/korosuke613/scraps/84794d9baed038)
  - ものすごく丁寧に解説および実験してくれてます。🥺
- [GitHub Enterprise でブランチに push や merge できるユーザーを制限したい](https://blog.beachside.dev/entry/2022/03/02/193000)