This question is an exact duplicate of:
We have a very large code base in mercurial. We have about a 6 month release cadence with 2 week sprints. For each release we have about 10 feature branches and maybe 5 or so people working per branch.
Now whether or not feature branches are a good idea is a question for another day.
Currently we do merge-downs/copy-ups from feature branches into the main QA line twice during that 6 months - once about 1/2 way through and once a few weeks before the end of the release. (specifically, merge-down from qa, then feature branch copies up).
The reason seems not to keep in sync with each other, but to enable some testing about half-way through the release.
This has caused a lot of angst about looming merges and a few nasty merge conflicts, but not as many as one might expect.
So I guess my questions are:
-Would having more frequent merges just for the sole purpose of keeping things in sync and preventing surprises create more churn or less churn?
-If so, what would be a good schedule? I've thought about this a bit - more frequent merges would require teams to have their code in good shape more often, which might not be a bad thing. Too often though might spread bugs around to all feature branches before they get a chance to be fixed.
We're using Hg, but I'm adding git as a tag because I think the issues are pretty much the same.