あんまり得策でないのでやめてほしいということと、しくじるとえらいことになるということを書きたかった雑記。なおこの文章内でのPRとはPullRequestの略。
やめてほしいこと
こんな流れ
- ブランチtopicを切って開発開始、すべての機能が整うまでここにマージする
- topicからfeature1を切って開発、コミットしてPRをする
- feature1がなかなかレビューされないのでfeature1からfeature2を切って開発、機能粒度的にちょうどいいところでコミットしてPRする。
- feature2を作ってる間に、feature1の修正内容を指摘されたので後続のfeature3としてブランチを切り、feture3で修正を行い、コミット。
そうするとこんな感じのブランチ構造になる
困ること
順当に最後尾であるfeature3からマージしていけばキレイにはまとまる。しかしながらこの場合、feature1がレビュー済みでも再度見る羽目になるという難点がある
しかしながら、feature1から2,3とマージするとそれはそれで悲惨なことになる。あたりまえだが、feature1がマージされてもその後マージしたfeature2とfeature3はブランチのとどまり続けてMergeされない、というのが以下の例
上記の場合だと、feature1がマージされてしまっているので、そのあとにfeature2をマージするとすでにtopicに取り込まれたあとのfeature1に対して変更差分がマージされるためfeature2の編集はtopicに合流されないままになってしまう。
そうならない場合にどうするべきかとなると、枝分かれをつくっていくのではなくちゃんと前提のものがマージされてからPRをつくるという形にするのが大切となる。以下がイメージ。
ブランチを多重にしないための心がけ
これが起きうる最大の要因は「レビュー遅く、マージができないので出しているPRに対して枝分かれして作らないと前に進まない」というところから発生しがちな問題なので、そういう状況にならない・選択させないようなレビュー体制や作業粒度をつくっていくことが肝要かなと思います。
