この記事は、LINE Advent Calendar 2018 の11日目の記事です。
開発3センターでサーバサイドの開発を行っている大原(@kory1202)です。
早速ですが私たちのチームでは Pull Request (PR) を master に向けて作る GitHub Flow に近い運用をしています。 この運用では PR を merge したときに別の PR も自動 close される場合がありますが、どのような条件で自動 close されてしまうのかちゃんと分かっていませんでした。 そこで GitHub Help > Closing a pull request の辺りを読んだのですが求める回答はなかったので本記事でまとめました。
自動 close とは
GitHub 上で出している PR が、その PR の画面の操作以外で自動的に close されることを指します。
具体例で示します。以下のグラフのようなコミットがあり master <-PR- develop
、 master <-PR- feature
の2つの PR があるとき。
(本記事では master <-PR- develop
は base を master にした develop ブランチの PR を意味します)
develop ブランチの PR を GitHub 上で merge すると、 feature の PR も自動で close されます。 これが 今回話す 自動 close です。
分かっていなかったこと
- base により自動 close される場合とされない場合はどんなとき?
master <-PR- develop <-PR- feature
のとき feature merge 前に develop を merge すると feature も close されてしまう?- master に Hotfix の変更が入った場合には develop 以下開発中の全てのブランチに master を取り込み直す必要がある?
- 操作によってはレビュー前の PR が本人も知らない間に merge & close されてしまうような大事故が起きる?
- レビュー完了前の PR が close してしまう場合はある?どんなとき?
上の5つに対する回答は下の方の「まとめ・所感」の節にあるので回答をすぐ知りたい方は「調査」を飛ばして「まとめ・所感」を見てください。
以下具体的に挙動を確かめます。
調査
PR の base や merge するタイミングなど運用方法は色々あると思いますが、ブランチは大体、本番環境・QA環境・他の3種類になっている気がします。 そこで今回はブランチを以下のように扱い、 PR の base と merge と自動 close に関する様々な場合の調査を行います。
- master: 本番環境
- develop: QA 中の環境
- feature: 他
特に、 feature の PR の base を master にするか develop にするかによる違いにフォーカスしていきます。
調査1: PR の base と自動 close の関係
調査1-1: feature ブランチが一つの場合
調査1-1-1: master <-PR- feature
の場合
上記の2つの PR が出ています。 develop に feature を取り込み、 master に develop を取り込む方法を考えます。
- 方法
- ローカルで develop に feature を merge して push
- GitHub で develop を merge
- このとき feature は自動 close される
調査1-1-2: develop <-PR- feature
の場合
上記の2つの PR が出ています。 develop に feature を取り込み、 master に develop を取り込む方法を考えます。
- 方法1
- GitHub で feature を merge
- GitHub で develop を merge
- 方法2
- ローカルで develop に feature を merge して push
- このとき feature は自動 close される
- GitHub で develop を merge
- ローカルで develop に feature を merge して push
上図のときに feature を取り込まずに develop を merge するとどうなるか。 base を develop にしている feature も close されるのかを調査した結果が以下です。
- feature の PR は close されない
- feature の PR を merge すると再度 develop ブランチの PR が作成できるようになる
- develop のブランチは feature を削除するか base を変えるまで GitHub から削除できなくなる
- ただし、無理やり
git push --delete origin develop
で develop を削除すると feature は close されてしまう
- ただし、無理やり
調査1-2:依存関係のある2つ以上の feature ブランチの PR がある場合
依存関係がある2つのブランチとは、 hoge という機能を新規追加する add_hoge ブランチと、更に機能を改良する update_hoge ブランチを考えると分かりやすいです。
add_hoge のレビュー完了より前に update_hoge の開発が進み同時に PR を出す場合です。 または、 hoge という機能の実装が大きくなり、 PR を小分けしてレビューしやすくした場合などもこうなります。update_hoge は add_hoge の変更を基に実装されているので、レビューの為に add_hoge <-PR- update_hoge
を作りたいかと思います。このとき PR の merge 操作に伴い自動 close がどうなるか以下で調査しています。
調査1-2-1: master <-PR- add_hoge
の場合
上記の3つの PR が出ています。 develop に add_hoge と update_hoge の変更を取り込み、 master に develop を取り込む方法は以下。
- 方法1
- GitHub で update_hoge を merge
- ローカルで develop に add_hoge を merge
- GitHub で develop を merge
- add_hoge が自動 close される
- 方法2
- ローカルで develop に add_hoge と update_hoge を merge
- GitHub で update_hoge の base を master に変更
- GitHub で develop を merge
- add_hoge も update_hoge も自動 close される
- 方法3
- ローカルで develop に add_hoge と update_hoge を merge
- GitHub で develop を merge
- add_hoge は自動 close されるが update_hoge は自動 close されない
- update_hoge を手動で close する
方法2と3は、 add_hoge のレビューが終わってないので add_hoge に update_hoge を merge したくない、しかし QA での確認は始めたいから develop には反映したいというわがままな事例です。 (理想はレビューが全部完了しブランチを整理してから develop に merge ですが、今回は自動 close の挙動の確認の為なので目をつぶってください)
方法2と3の事例から、 update_hoge は base が master でない為 master に取り込まれても自動 close されないことがわかりました。
調査1-2-2: develop <-PR- add_hoge
の場合
上記の3つの PR が出ています。 develop に add_hoge と update_hoge の両方を取り込み master に develop を取り込む方法は例えば以下です。
- 方法1
- GitHub で update_hoge を merge
- GitHub で add_hoge を merge
- GitHub で develop を merge
- 方法2
- GitHub で add_hoge を merge
- GitHub で update_hoge の base を develop に変更
- GitHub で update_hoge を merge
- GitHub で develop を merge
- 方法3
- ローカルで develop に update_hoge を merge して push
- add_hoge は自動 close されるが update_hoge は自動 close されない
- update_hoge の base は develop に変更できなくなる。
There are no new commits between base branch 'develop' and head branch 'update_hoge'
とエラーが出る。
- update_hoge は手動で close する
- ローカルで develop に update_hoge を merge して push
調査2: Hotfix が master に入ったときの対応
結論から言うと master に Hotfix が入ったとき、 develop や feature に master を merge し直す必要はないです。 PR の base 側のブランチに変更が起きても、コンフリクトが起きていない限り自動 close されます。
ただし、master を merge し直す必要がないのは自動 close される点に限った話です。 実際には最新の master に開発したコードを取り込んだときの動作が正常か確認したいので develop や feature に master を取り込み直すことになると思います。
以下の調査では feature ブランチの PR の base を master に設定するか develop に設定するかで必要な対応の違いを確認しました。
調査2-1: master <-PR- feature
の場合
Hotfix が発生した時の図が以下。
master を feature に merge した場合、 develop に再度 feature を merge する必要があります。 GitHub で develop を merge したとき feature も自動 close させる為です。
GitHub の自動 close する PR を探す処理はgit branch --merged
になっていて master から feature の先頭の commit が辿れないと自動 close されないようです。実際の実装については GitHub Community で聞いたところ、それで合っているとのことでした。(質問する場所を完全に間違えていたのですが優しい回答をしてもらえました)
調査2-2: develop <-PR- feature
の場合
Hotfix が発生したときの図が以下。
こっちは簡単です。コンフリクトがあれば feature を更新して動作確認してから develop に merge して close です。
まとめ・所感
「分かっていなかったこと」に回答する形でまとめます。
base により自動 close される場合とされない場合はどんなとき?
PR の base の設定や操作によって close されるタイミングについて以下にまとめます。
- base のブランチに変更が取り込まれるとき自動 close される
- ただしこのとき PR のブランチの先頭が base に merge されている必要がある
- ローカルから merge して push でも変更が取り込まれれば close される
- base ブランチが消えると自動 close される
- base ブランチの PR が close しても自動 close されない
- base が master でない PR は master に取り込まれても自動 close されない
master <-PR- develop <-PR- feature
のとき feature merge 前に develop を merge すると feature も close されてしまう?
上述の通り close されない
コンフリクトが起きたときだけ必要です。 master を feature ブランチに merge した場合は、 develop に再度 feature ブランチを merge する必要があります。
操作によってはレビュー前の PR が本人も知らない間に merge & close されてしまうような大事故が起きる?
起きません。 流石にそれはなかったので安心しました。
レビュー完了前の PR が close してしまう場合はある?どんなとき?
あります。QA と PR のコードレビューを同時に進める場合に起きる気がします。
develop <-PR- feature
のとき、 レビュー完了前の feature の QA を進める為にローカルから develop に feature を merge してしまうと feature の PR は close されてしまいます。
master <-PR- feature
のときには同じ操作をしても feature は close されません。
PR の base を master にする運用のリポジトリと develop にする運用のリポジトリの両方の開発を同時に行う場合に一回私はこれをやったことがあるので注意したいです。
おわりに
本記事では GitHub の自動 close の挙動を確認しました。自動 close (auto close)されないときがどんな条件か微妙に分からないという方のお役に立てれば幸いです。 GitHub の PR の大きな事故もまとめようと思ったのですが、最近は事故が起きないように修正されてきているのか想定外のタイミングで close されたりされなかったりするくらいでした。 もし、 GitHub の操作ミスなどで大きな事故が発生するパターンなどがあったらtwitterなどで教えていただけると嬉しいです。
明日は同期の黒澤くんによる「業務でSpringBootを半年間使ってみて思ったこと」です。お楽しみに!