参考サイト
はじめに
先日、お世話になっている会社のあるエンジニアさんが、緊急ということでプルリク後セルフマージするという事がありました。
そのエンジニアさんはドメイン知識も豊富な頼れるエンジニアさんなので、その方のセルフマージは許せますが、経歴が若いエンジニアさんにそういうことをやられると困ります。
なんか制限できないかなーといろいろ調べてたら、参考サイト様に出会いました。
ちょっとやってみます。
やってみた
参考サイト様におんぶにだっこでやってみます。
まずレポジトリの Setting
から Branches
を選択します。
Branch protection rules
で 保護するブランチを選択します。
まぁ大体のプロジェクトは master
かなと。
選択すると以下のような画面に遷移します。
Protect this branch
をチェックすると諸々チェックボックスが現れます。
参考サイト様に詳しく書かれているんで、改めて説明することないですが、現在のプロジェクトに合いそうなものだけ説明していきます。
1. Require pull request reviews before merging
コチラが今回のやりたかったことのメイン。マージ前にレビューを必須にするという設定です。
チェック入れます。
するとなんかセレクトボックスが出てきました。
Required Approving reviewsと書いているので、おそらくプルリクに対してのApproveの数だと思います。
とりあえず1で。
2. Dismiss stale pull request approvals when new commits are pushed
Approveされた後更にコミットされた時に、再度レビュー挟むか?みたいな設定のようです。
これもチェック入れます。
3. Require review from Code Owners
コード所有者のレビューを必須にすると機能
基本的に自分のプルリクは自分がApprove出来ないようなので問題ないですが、やっぱり重要な人のレビューを通したいというのはあります。
.githubディレクトリに CODEOWNERS
というファイルを追加して、コードの所有者を設定できます。
* @ユーザー名
とかってやると、指定のレポジトリが全て指定ユーザが所有者になります。
これもチェックしておきましょう!
4. Require status checks to pass before merging
CIなどでユニットテストを走らせて、それが通らないとマージできないようにするみたいなことが出来るようです。
現状お仕事先ではJenkinsを導入しているので使えるのですが、まだ連携できてません。なので今回は見送ります。
5. Require signed commits
署名済みコミットが必須になるチェックです。
自分はやっているんですが、他のエンジニアが設定しているかを確認しないといけないので、こちらも一旦見送ります。
6. Include administrators
管理者もマージ必須にするかどうかのチェックです。
これはどうするか悩むところです。。。
夜間の緊急対応などの考えるとチェックは付けたくないなと思います。
ただ、管理者の場合はこのルールの編集もできるので、そのときだけこのチェックを外せばよいのではと思います。
なので付けちゃいます!
ちなみに、この設定を付けるときと付けないときでどんな表示になるのかなと確認すると、以下のようになりました。
チェックを付けた場合
マージボタンが押せないようになってます。
チェックを付けない場合
赤い表示になっていますが、管理者なのでマージが実行できます。
ということで最終的に今回のルールは以下のようになりました。
おわりに
実際にどの程度、影響があるかどうかは試してみないとわかりませんが、github側でルールを作ってもらうことで、間違ってマージしちゃったなどもなくなるので、良い方向に転がると思っています。
今日はココまで。
お腹痛い。。。