「頻繁に」マージするのが良いですか、それとも完了後にのみ機能ブランチの大きなマージを行う方が良いですか？
複数のブランチAとBが開発されており、インクリメンタルな「バグ修正」ブランチCがあるとします。
これでCはすでに「終了」しており、マスターにマージされています。 AとBはまだ開発中であり、別のバグ修正ブランチがマスターにマージされる前に（おそらく）修正されません。
新しい機能ブランチでCをできるだけ早くマージすることは良い考えですか？新機能をmasterにできる限り近づけるために？それとも、新しい機能を独自の「世界」で開発し、完成したらマスターにマージするだけのほうがいいですか？
とにかく衝突があるので、それらを修正するために時間を費やす必要があります。
ブランチの寿命が長いほど、メインブランチから分岐でき、より複雑で、最終的にマージが複雑になります。 10個の小さな競合は、1つの大きな競合よりも解決が簡単であり、開発者が重複したり、労力を浪費したりすることを実際に防ぐことができます。そのため、masterをAとBに定期的にマージする必要があります。 1日1回はかなり一般的な推奨事項ですが、ブランチで多くのアクティビティがある場合は、1日に複数回マージすることをお勧めします。
競合の解決を簡単にすることに加えて、Cはバグ修正ブランチであることを具体的に説明します。開発者として、バグにつながる動作を繰り返したり、誤ったデータに基づいてテストを記述したりしないように、ブランチに最新のバグ修正をすべて含めたいと思います。
とにかく衝突があるので、それらを修正するために時間を費やす必要があります。
競合があることがわかっている場合は、別の分岐戦略を採用することをお勧めします。可能な限り、同じブランチ上の同じファイルへの複数の変更を保持し、競合の数を減らすか排除します。ストーリーを可能な限り完全に独立するようにリファクタリングし、ブランチを再構築して、複数のストーリーをカバーする可能性があります（ブランチ、機能、ストーリーは常に交換可能ではありません）。
最終的にA、Bをマスターにマージして単一のコードベースを維持するつもりであると想定すると、マスターから離れすぎてはいけません。マスターからの逸脱が長すぎると、特にバグ修正やその他の開発がマスターにマージされてA、Bが開発されているときに、確実に競合が発生します。
私は次のような戦略を検討します
- A、Bの責任者は、マスターを注意深く監視し、変更をマージする必要があります。
- さらに良いことに、自動化をビルドしてテストしている場合は、A、Bがマスターにマージされ、夜間にテストに合格することを確認してください。
- 他の回答に対するコメントに基づいて、A、Bの開発にはしばらく時間がかかるようです。この場合、A、Bもマージして、最終的に両方をマスターにマージする際に大きな問題が発生しないようにすることも検討できます。
- より高いレベルで、長い開発の2つの別個の行が必要な理由を考えてください。小さなマージに分解できますか？個別のマイクロサービスに侵入できますか？
通常しばしばは大規模なものよりも優れています。
より小さく、より頻繁に、プルリクエストがほとんど常に優れています。
私は主に構成フラグの使用を開始しました。これにより、初期の小さいプルリクエストを実行できるようになり、コードをより簡単にマージできるようになりますが、機能は非アクティブのままにできます。プルリクエストが小さいほど、プルリクエストの総数が多くても、コードの確認が簡単になります。どんな種類のほとんどの人間も、大量のプルリクエストの意味のあるレビューを行うことができません。大きなコード変更のすべての可能な影響を理解するのは、精神的なRAM=にすぎます。
構成フラグの作成には余分なオーバーヘッドがあるため、小さな機能では価値がありません。ただし、プルリクエストはとにかく小さくなります。
ただし、機能を一度にリリースする必要がある場合もあります。それでも、その目的のために作成された別のブランチに対して、より小さなプルリクエストを実行する方がよい場合があります。
私の同僚のほとんどは、誰かが大規模なプルリクエストを作成するとうめきます。ほとんどの場合、そうです。
また、コミットを別のブランチにチェリーピックする必要がある場合があることにも注意してください。チェリーピックが必要なものを1つのコミットに入れることができる場合、それを他のブランチに移動するのが簡単になります。これは、実際にはコミットが少ない方が良いケースですが、チェリーを利用する場合の標準プロセスではありません。
Martin Fowlerによるリファクタリングでは、彼が与えるアドバイスは、ブランチをマスターから1日以上分岐させないことです。 IIRC、小さな変更を加え、何も壊していないことを確認するためにテストしてから、マージし直してください。
本当に有効な変更が完了して使用できない場合の別のオプションは、機能フラグの後ろに配置して、マスターにマージできるが、何も壊すリスクがないようにすることです。その後、使用する準備ができたら、機能フラグを削除できます。