git-flow releaseブランチで作業中にfeatureブランチをdevleopにマージしてもいいか

Question

git-flowのReleaseブランチで作業中にfeatureブランチをdevleopにマージしてもいいか

社内でGit-Flow(A successful Git branching model)を導入しました。

一般的なGit-Flowに習い、リリース作業のためにdevelopからreleaseブランチを切り、バージョンアップや受け入れテストを行った後、master及びdevelopにマージしています。

最近、開発速度が上がったために、releaseブランチで受け入れテストを行っている最中に、完成したfeature→developへのプルリクが複数上がるようになりました。

feature→developのマージタイミングとして正しいのはどちらなのでしょう？

1. feature→developのマージをrelease完了まで待たせる
2. feature→developのマージをrelease完了を待たず行う

ひとまず安全そうな 1 で運用していますが、releaseが完了するまで結合テストができず、開発者の間で不満が発生しています。

このシチュエーションについて語っているサイトが見つからず、皆様ではどのように運用しているのかご意見、ご指摘いただきたいです。

Answer 1

こんにちは。
個人的な意見で回答します。

自分は間違いなく2の運用を選びます。
理由は、release ブランチを「切る」というのは、そのタイミングでリリースへ向かう道と開発を進める道を分岐していることに他ならないからです。

例えば、高速道路を想像して下さい。release ブランチを切ることをパーキングエリアへの分岐だとみなしたとき、1の運用はパーキングに進入してから復帰するまで (リリース作業が完了するまで) 高速道路側の流れをブロックすると言っています。これが不合理であることは明らかでしょう。

ただし、2の運用にすることで、release 作業にかかる変更が release ブランチに積まれている間に develop 側でも変更が進み、develop への合流の際に競合が発生する可能性が出てきます。
1の運用では (ブロックしているので当たり前ですが) 競合は発生しません。しかし、競合を回避したいがためにブランチの進行を止めるというのは Git の考え方自体に反しています。

Comments

[nop0x0000]

回答ありがとうございます。

解りやすい例えのおかげで、 1 の場合の弊害をよく理解できました。
2 の運用のほうが現状にあっているようなので、変えていこうと思います。

競合の発生が怖いですが、こまめなリベースやトピックの粒度を適度に小さくするなどで対策していこうと思います。
(レガシーな現場での文化づくり・教育って大変ですね...)