コード日進月歩

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

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

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

やめてほしいこと

こんな流れ

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

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

f:id:shinkufencer:20190409001307p:plain
数珠つなぎのブランチ

困ること

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

f:id:shinkufencer:20190409001333p:plain
コレ自体もPR読み解く難易度があがるのでやめてほしい

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

f:id:shinkufencer:20190409001412p:plain
マージ済みのブランチにMergeCommitが入るという悲惨な状況

そうなると順当に都度マージするまで待って細かくマージするほうが正解だなと思うわけです。

f:id:shinkufencer:20190409001452p:plain
順当にtopicから切る

そうならないように

これはレビュー遅い問題と、なかなかPR進まないことが問題なので、こんなブランチを切っちゃうような状況を作らないことが大事だな…とつくづく思います。

関連リンク