GitHubでブランチ保護を有効にする

GitHubを利用してチーム開発をしているあなた!
こんな経験はありませんか?
｢せっかくCIを設定しているのにテストに失敗したプルリクをマージしてしまった!｣
｢レビューが終わっていないのにマージされてしまった!｣

とはいえ､そんなことする人はいないと思いますが､うっかりミスは誰でも､どんなときでも起こりえます｡
事故防止のためにも､ブランチ保護はしっかりと設定していきたいものです｡

ということで､ブランチ保護の設定方法､項目について､簡単にですが説明していきたいと思います｡

# ブランチを保護する
無料アカウントでは､privateリポジトリの保護は設定できません｡
Pro(OrganizationならTeam以上)にアップグレードするか､publicリポジトリに設定してください｡

対象のリモートリポジトリにアクセスし､`Settings`を選択
![2019-07-02_11h02_31.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/74711/0cb77d18-dffe-bc47-3ddc-16d1ce3fa45e.png)

`Branches`を選択し､`Add rule`でブランチ保護ルールを追加します｡
![2019-07-02_11h03_15.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/74711/9adc00b5-db6c-2bec-d30b-a7812fe96cf6.png)

保護対象ブランチの名前等を入力して`Create`で削除などの操作を制限できます｡
![2019-07-02_11h04_36.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/74711/7a258241-237b-8b4d-1b6c-7a3b0ba5ab00.png)

その他の設定項目について､簡単ですが説明していきたいと思います｡

## 保護設定項目
### Branch name pattern
ブランチ名や`glob`でパターンを指定します｡
※ `*[master|develop]*`, `release-*`, etc...
指定されたブランチは､削除できなくなります｡

### Require pull request reviews before merging
pull requestによるレビューを必須にします｡

#### Required approving reviews
マージするために必要な承認数を設定します｡
1を設定したら､最低1人の承認を得なければマージできません｡

#### Dismiss stale pull request approvals when new commits are pushed
pull request承認後に新たな`commit`が`push`された場合､再度承認されるまでマージをできないように設定します｡

#### Require review from Code Owners
コードオーナーのレビューを必須にします｡
コードオーナーは､プロジェクトルートに`.github/CODEOWNERS`というファイルを追加することで設定できます｡
※プロジェクトルート直下に`CODEOWNERS`を作成しても適用されますが､`.github/CODEOWNERS`としたほうがわかりやすいと思います｡

```text:.github/CODEOWNERS
# 全ファイルの所有者
* @username1

# 特定の拡張子のファイル所有者
*.html @username2
*.js @username2
*.scss @username2

# 特定のディレクトリ直下ファイルの所有者
# Eメールアドレスも指定可
tests/* example@github.com
```

#### Restrict who can dismiss pull request reviews
レビューを却下できるユーザー/チームを設定できます｡
一旦承認されていても､ここに設定されたユーザーは､そのレビューを却下することができます｡

### Require status checks to pass before merging
ステータスチェックを有効にします｡
[GitHub API v3のStatuses](https://developer.github.com/v3/repos/statuses/)を利用することで､ステータスチェックをカスタマイズすることが可能です｡

#### Require branches to be up to date before merging
ベースブランチに対して､最新であることを必須にする設定です｡
その他の設定(レビュー必須など)をしている場合､ベースから取り込んだ`commit`もPRの作成とレビューが必須になります｡

#### Status checks found in the last week for this repository
連携しているサービス一覧(Circle CI､ Travis CIなど)が表示されます｡
`push`時に確実に通しておきたいテストや処理がある場合は､対象のサービスにチェックを入れます｡

### Require signed commits
署名済みコミットを必須にします｡
署名済みコミットについては､以下をご覧ください｡
[Git のさまざまなツール - 作業内容への署名](https://git-scm.com/book/ja/v2/Git-%E3%81%AE%E3%81%95%E3%81%BE%E3%81%96%E3%81%BE%E3%81%AA%E3%83%84%E3%83%BC%E3%83%AB-%E4%BD%9C%E6%A5%AD%E5%86%85%E5%AE%B9%E3%81%B8%E3%81%AE%E7%BD%B2%E5%90%8D)

### Include administrators
Owner/Admin権限所有者もブランチ保護制限の対象にする設定です｡

### Restrict who can push to matching branches
`push`できる人/チームをホワイトリスト型で指定します｡
Organizationのみの項目です｡

## あとがき
｢失敗する余地のあるものは失敗する｣[^1]
[^1]: [マーフィーの法則](https://ja.wikipedia.org/wiki/マーフィーの法則)
ミスは必ず起こるものです｡
不安なく開発をするためにも､リポジトリを作成した際には､忘れずに設定したいですね｡
私の場合､`master`は`Restrict who can push to matching branches`だけを設定し､担当者かCIサービスが`push`できるように設定
`develop`は最低1人の承認､テストのパスを必須条件にし､`Include administrators`にもチェックしています｡
担当しているサービスが少人数開発なので､必要最低限の設定に留めています｡
ブランチモデルやワークフローによって適した設定は変わってくると思いますので､最適な設定を模索してみてください｡

# 参考
[Configuring protected branches](https://help.github.com/en/articles/configuring-protected-branches)
[About protected branches](https://help.github.com/en/articles/about-protected-branches)
[About code owners](https://help.github.com/en/articles/about-code-owners)
[About required commit signing](https://help.github.com/en/articles/about-required-commit-signing)
[Git のさまざまなツール - 作業内容への署名](https://git-scm.com/book/ja/v2/Git-%E3%81%AE%E3%81%95%E3%81%BE%E3%81%96%E3%81%BE%E3%81%AA%E3%83%84%E3%83%BC%E3%83%AB-%E4%BD%9C%E6%A5%AD%E5%86%85%E5%AE%B9%E3%81%B8%E3%81%AE%E7%BD%B2%E5%90%8D)
[[GitHub] ブランチの保護設定を活用しよう 【レビューが通るまでマージさせんぞ】](https://dev.classmethod.jp/tool/github/protect-branch/)