コード日進月歩

しんくうの技術的な小話、メモ、つれづれ、など

PullRequestを出したブランチにそのままブランチを切ってを繰り返して開発すすめてしまうと、PRのマージ順番をしくじった場合に意図違いになるので控えてほしい

あんまり得策でないのでやめてほしいということと、しくじるとえらいことになるということを書きたかった雑記。なおこの文章内でのPRとはPullRequestの略。

やめてほしいこと

こんな流れ

  1. ブランチtopicを切って開発開始、すべての機能が整うまでここにマージする
  2. topicからfeature1を切って開発、コミットしてPRをする
  3. feature1がなかなかレビューされないのでfeature1からfeature2を切って開発、機能粒度的にちょうどいいところでコミットしてPRする。
  4. feature2を作ってる間に、feature1の修正内容を指摘されたので後続のfeature3としてブランチを切り、feture3で修正を行い、コミット。

そうするとこんな感じのブランチ構造になる

数珠つなぎのブランチ

困ること

順当に最後尾であるfeature3からマージしていけばキレイにはまとまる。しかしながらこの場合、feature1がレビュー済みでも再度見る羽目になるという難点がある

コレ自体もPR読み解く難易度があがるのでやめてほしい

しかしながら、feature1から2,3とマージするとそれはそれで悲惨なことになる。あたりまえだが、feature1がマージされてもその後マージしたfeature2とfeature3はブランチのとどまり続けてMergeされない、というのが以下の例

マージ済みのブランチにMergeCommitが入るという悲惨な状況

上記の場合だと、feature1がマージされてしまっているので、そのあとにfeature2をマージするとすでにtopicに取り込まれたあとのfeature1に対して変更差分がマージされるためfeature2の編集はtopicに合流されないままになってしまう。

そうならない場合にどうするべきかとなると、枝分かれをつくっていくのではなくちゃんと前提のものがマージされてからPRをつくるという形にするのが大切となる。以下がイメージ。

順当にtopicから切る

ブランチを多重にしないための心がけ

これが起きうる最大の要因は「レビュー遅く、マージができないので出しているPRに対して枝分かれして作らないと前に進まない」というところから発生しがちな問題なので、そういう状況にならない・選択させないようなレビュー体制や作業粒度をつくっていくことが肝要かなと思います。

関連リンク