機能ブランチをメインラインにマージするのに適した頻度はどれくらいですか？
Mercurialには非常に大きなコードベースがあります。約6か月のリリースケイデンスと2週間のスプリントがあります。各リリースには、約10の機能ブランチがあり、ブランチごとに5人程度の人が作業しています。
機能ブランチが 良いアイデアであるかどうか は別の日の問題です。
現在、機能ブランチからメインQAラインへのマージダウン/コピーアップを6か月の間に2回行っています。 （具体的には、QAからマージダウンし、機能ブランチをコピーします）。
その理由は、相互に同期し続けているのではなく、リリースの半分くらいまでのテストを可能にするためです。
これは、迫り来るマージといくつかの厄介なマージ競合について多くの不安を引き起こしましたが、予想されるほどではありません。
だから私の質問は：
同期を維持し、予期せぬ事態を防ぐことだけを目的として、より頻繁にマージを行うと、チャーンの増加または減少が発生しますか？
もしそうなら、どのようなスケジュールが良いでしょうか？私はこれについて少し考えました-より頻繁なマージはチームが彼らのコードをより頻繁に良い形にすることを要求するでしょう、それは悪いことではないかもしれません。ただし、修正の機会が得られる前に、すべての機能ブランチにバグが拡散する可能性があります。
Hgを使用していますが、問題はほとんど同じだと思うので、タグとしてgitを追加しています。
良いスケジュールは、安定したコード（または「安定する可能性が高い」コード）のみをマージすることです。
テストを開始するために途中でマージし、現在コーディングしている機能の一部が完了していないことがわかっている場合は、これらの機能に関するテストのフィードバックが確実に得られます。
あなたが尋ねなければならない質問は、「私はすでに構築したものの完全性に自信がありますか？」です。
答えが「はい」の場合、テストできます。そうでない場合は、テストしても意味がありません。コーディングを続けてください。
編集：実際には、開発者の1人がそれ自体で問題のない機能を終了したと言うたびに、部分的にテストを開始することができます。