main branchをtopic branchにmergeするのか、しないのか

created: 2025-02-05

Gitで開発物を管理する時にたまに話題になる話のひとつに、「main branchをtopic branchにmergeするか否か」という話があると思っている。

ここでは、main branchはチームで共有している本筋のブランチで、topic branchは機能開発のためのブランチでありtopic branchは個人または極少数が使うブランチのことを指す。 話の概要は、topic branchをmain branchにマージするとき、topic branchの分岐元が古いコミット(main branchの最新でないコミット、または、充分な新しさでないコミット)だった場合に、main branchとの間でコンフリクトが起こることがある。この時に、コンフリクトの解消をどこで行うか、という話になる。

戦略として大きく2つ考えている。

• topic branchをmain branchの最新にrebaseし、rebaseの過程でコンフリクトを解消する
• topic branchにmain branchをmergeし、mergeの過程でコンフリクトを解消する

結論は無く、その時その時のチームで決めればよいことなので、どちらが良い悪いを書くつもりはない。

それぞれの特性についてはAtlassianの Merging vs. Rebasing | Atlassian Git Tutorial を読むのが良い。

いくつかのチームの話を見聞きして、由来やシーンによってどのように判断されて戦略が使われてきたのかが少し見えたのでメモしておく。

topic branchをmain branchの最新にrebaseし、rebaseの過程でコンフリクトを解消する戦略

rebaseする場合、当然rebaseする前のブランチとは異なるコミットになる。 そうすると、rebaseの前からそのブランチに注視していたとして、新たなコミットだけを見て変更を確認することが難しい。 rebaseの過程でmain branchの変更を取込むし、rebaseの過程でコンフリクトを解消しているしコンフリクト解消はコミットの履歴には出現しないからだ。

そうなると、topic branchが短期間しか存在しない開発において選ばれやすい戦略だろう。

また、branchにcommitする者とbranchをレビューする者が密に意思疎通できる場合も採用しやすいだろう、rebaseした事情やmain branchの変更内容を充分に共有できる・共有できているという前提があるからだ。

では、そういった体制の開発はどこにあるのかというと、フルタイムメンバーのみのチームにある。フルタイムジョブでの開発などだ。

また、そういった体制においては、開発の歴史はコミットログに全ては現れなくてもよい。密に意思疎通しているプラットフォームが別に存在するはずだし、開発の歴史の必要な部分だけがコミットログに出現していた方が都合が良い。

topic branchにmain branchをmergeし、mergeの過程でコンフリクトを解消する戦略

topic branchにmain branchをmergeするということは、topic branchを見ると全ての歴史が分かることになる。

こちらの戦略は、前節の結論と反対の側面がある。topic branchには、実装上必要である以上の情報が乗ってくる。topic branchを開発している間にmain branchに別の機能が入った、等の情報のことだ。

この側面から、topic branchが長い間存在して、topic branchをレビューする者も長い間存在する開発においては選ばれやすい戦略だと思った。

また、フルタイムではないメンバーを含むチームや意思疎通が密ではない体制で選ばれやすいだろう。

main branchが更新されたからmergeしてきたという時に、mergeしてきたという履歴が残るので会話する必要が少ないからだ。また、rebaseされないので過去に見たコミットが変わることが無く、新たに追加されたコミットだけを見ていればよいからだ。 topic branchを最初から見直すのは大変だし、フルタイムでないメンバーがtopic branchを少しずつ見直していく間にさらにrebaseが発生すると悲惨だろう。