結論から言うと、「Require approvals」を見ましょうというお話。
はじめに
某オウンドメディアの運用のお話です。AWS上にWordPressでサイトを公開して1年ちょっと。今はたまに顧客からの問い合わせを受けたり、カスタマイズの依頼を受けて改修したりしています。
ソースコードはGitHub上で管理していて、カスタマイズの依頼があるとブランチを作ってコードを記述し、プルリクエストを経てからmasterにマージして本番リリースという比較的簡単な運用でやっています。（比較的簡単というのは、リリース時にタグを切ったりしてない・・・という意味で）
もともとレビュー必須だった
前述のとおり、プルリクエストを経てmasterにマージする手順で運用していて、管理者のみがmasterにマージできるように制限をかけていました。だから開発フェーズでは各担当者はプルリクエストを出して、管理者がレビューしてマージという流れで進めてきて、運用フェーズに移行した後も運用は変えず、担当者が自分一人だけになっても自分でプルリクエストを出して、管理者である自分がレビューしてマージという流れを継承して運用していました。
あるとき突然に・・・
ある日、いつもと同じように顧客からの依頼でカスタマイズを行い、ステージング環境にリリースするためにプルリクエストを出して、自分でマージしようとしていました。しかし、どうやっても緑色の「Squash and merge」のボタンが出てこない！
「何かコメントを入れなきゃいけないんだったっけ？」とか「気づいてないコンフリクトがあるのかな？」とか色々考えて操作してみたけどどうにもならない。顧客とリリース日を決めてあるし、さて困った・・・
一旦回避してリリース
取り急ぎ、リポジトリの管理者になっている他の人に依頼してマージしてもらったのでリリース自体はできましたが、いつも依頼するのも面倒なので調査しました。
自己レビューでリリースするのは危険なのでは？というご意見もあろうかとは思いますが、ここではその話は置きます。
分かったこと
リポジトリの設定画面に行って、Branchesを選んでブランチ名の所のEditを選ぶとこのような画面になります。
ここでRequire approvelsのチェックがONになっているとGitHub Docsに書かれている通りpull request をマージするには、リポジトリに 書き込み または 管理者 権限を持つユーザーからの指定数の承認レビューが必要となるのですが、これは同時にこのDocsの一番下に書かれている通りPull Requestの作者は、自分自身のPull Requestを承認することはできませんという状態を惹き起こします。つまり自分でプルリクエストを出して自分でマージする運用ができないということになります。
疑問として残っていること
今までできていたことが突然できなくなる・・・ということがあっても良いのかどうか、甚だ疑問ではありますが、これはGitHubのポリシーなのであれば仕方ないと思います。しかし、会社から任されてる一人プロジェクトで、自分でプルリクエストを出して、自分で承認してマージという運用は少なくないと思うのに、ググっても「Require approvals」を外せば行けますよという情報が見つけることができませんでした。皆さんどうしてるのだろうかというのが一番大きな疑問です。
あとは「Require approvals」を外したときに、プルリクさえ出せばだれでも勝手にマージできてしまうのではないかという危惧があります。そのあたりはおいおい調べないといけませんね。皆さんはどんな運用をされてるのでしょうか・・・。