これはなに
エンジニアとして働くうえで大多数の人が、コードを書いたあと、それをマージする前に「レビューをしてもらう」という工程が発生する。
このレビュー待ちの間にどんな行動を起こすか、レビュー待ちというステータスを考慮してどんなタスク分割を考慮したらよいか、ということに対する個人的な考えのメモである。
前置き
GitHub等を用いてコード管理をしているところでは、ほとんどが各自の機能開発や修正ごとにPull Requestを発行し、それを元に他人にコードレビューを依頼し、その後approveないしcommentをもらうまで待つという状態が発生するはず。
すごく初歩的な悩みではあると自負してはいるのだが、最近の自分の悩みとして、このPull Requestのマージ戦略について Squash Merge を採用している時にずっと抱えていたモヤモヤがあった。
スカッシュマージの悩み事
Squash Mergeの仕様として、あるPull Requestにcommit されたものたちはそれがマージされる際に一つのcommitにまとめられる（=> squashされる）というものがある。
これはつまりPull Request時のcommit logとマージされたあとのcommit logが異なるということにつながる。（もちろんこれにはメリットがたくさんあるのだがここでは省略する。）
今所属している組織では基本的にのこのSquash Merge戦略を採用していて、今までの現場で慣れていなかった自分にとってはこの環境において主に以下のような開発の流れを行った時に悩みを抱えていた。
master(main)からbranch Aを切る
branch AをPull Requestに出す
branch AがIn Reviewの間にbranch Aからbranch Bを切る
branch BもPull Requestを出す
branch Aのレビューが完了しマージする
branch Bにてconflictが発生する
なぜこのような挙動になるかというと、5のSquash Mergeによってmasterに入ったあとのcommit logが変化し、Gitがそれをconflictと判定してしまうせいである。
何がいけなかったか？
そもそも論、このような挙動を直接解決すべきというよりは個人的な開発のやり方に問題があったと感じている。
上記の方法だとbranch Aに修正依頼があった時branch Bにも取り込まなければいけない / branch Bの作業に手戻りが発生する可能性がある
作業AがIn Reviewのとき、その結果に依存するような作業Bは開始すべきでない
というような考えに至った。
ではレビュー待ちのとき、どうすべき？
基本的には上で示した例でbranch Aのレビュー待ちリードタイムを減らす取り組みをチーム全体で考えつつ、その間の作業はなるべくレビュー待ちの成果物に依存しないものにすべきであると感じた。
この考え自体はSquash Mergeを採用していなくて上記のようなケースでほとんど問題ごとは起きないような環境でも意識すべきだと思った。
ある一連の作業においてPRを分けた複数ブランチのステータスをすべて同時に考えなくてはいけないような状況はなるべく避けるべき。
さいごに
これを理解していなかった自分は最初正直やりづらいなーと感じていたけど、思い返してみればこのやり方で実際何度か孫ブランチを作って作業を進めた結果、親ブランチの修正によって手戻りが発生した経験もあったので考えを改めるべきだなと思った。
このあたり、DevOps的観点においてはどのように考えるべきなのだろう...おすすめの書籍や記事があれば教えていただけると嬉しいです。