Is it better to merge “often” or only after completion do a big merge of feature branches?

Question

Say multiple branches are being developed, A and B, as well as a incremental "bug fix" branch C.

Now C is already "finished" and merged into master. A and B are still in development and will not be fixed before (maybe) another bug fix branch is merged into master.

Is it a good idea to merge C as soon as possible in the new feature branches? So that the new features stay as close to master as possible? Or is it better to let the new feature be developed in their own "world" only merging into master once they are finished?

There will be conflicts anyhow, so time needs to be spent on fixing those.

Answer 1

The longer a branch lives, the more it is able to diverge from the main branch and the messier and more complicated the resulting merge will be when it's finally finished. Ten small conflicts are easier to resolve than 1 massive conflict, and may actually prevent developers from duplicating or wasting effort. Given that, you should merge master into A and B regularly; once a day is a pretty common recommendation, though if you have a lot of activity on your branches you may wish to merge multiple times a day.

In addition to making conflict resolution easier, you specifically mention C is a bugfix branch. As a developer, I'd want my branch to have all of the latest bugfixes, to ensure I'm not repeating behavior that led to a bug, or writing tests based on erroneous data.

There will be conflicts anyhow, so time needs to be spent on fixing those.

If you know there will be conflicts, you may wish to adopt a different branching strategy. Keep multiple changes to the same file(s) on the same branch whenever possible, and you reduce or eliminate the number of conflicts. Refactor stories so that they are completely independent as much as possible, and rework branches to possibly cover multiple stories (branch, feature, and story are not always interchangeable).

Answer 2

Assuming your intention is to eventually merge A, B back into master and maintain a single code base, it is never a good idea to deviate from master too far. Deviating from master for too long, especially when bug fixes and other development are merging to master as A, B are being developed, will certainly cause conflicts.

I would consider strategies similar to following

1. Whoever is responsible for A,B should watch master closely and merge in any changes.
2. Better yet, if you have build and test automation, make sure A,B merge in master, and pass tests nightly.
3. Base on you comment to other answer, it seem that A,B could take a while to develop. In this case, you may even consider to have A,B merge each other as well so that in the end you don't have major trouble merging both back into master.
4. At a higher level, think about why you need 2 separate line of long development. Could you breakdown into smaller merges? Could you break into separate micro services?

Answer 3

Usually often is better than a massive one.

Smaller, more frequent, pull requests are almost always better.

I've started using configuration flags primarily so that I can do early smaller pull requests so that I can, in turn, merge code more easily, but leave the feature deactivated. The smaller the pull request, the easier it is to review the code, even if there are more total pull requests. Most humans of any sort will not be able to do meaningful reviews of massive pull requests. It's just too tough on one's mental RAM to understand all the possible implications of a massive code change.

There is extra overhead in creating a configuration flag, so it's not worth it on smaller features. But then your pull request will be small anyway.

There may be situations, however, where the feature has to be released all at once. Even then it might be better to do smaller pull requests to another branch made for that purpose.

Most of my colleagues groan when someone creates a massive pull request, and for the most part, rightly so.

Also note that sometimes I need to cherry pick commits into a separate branches. If what needs to be cherry picked can be put into a single commit it makes it easier to move it around to other branches. This is a case where actually having few commits is better, but its not exactly the standard process if your cherry picking around.

Answer 4

In Refactoring by Martin Fowler, the advice that he gives is never to let a branch be branched off from master for longer than a day. IIRC, you should make a small change, test to make sure that you did not break anything, and then merge it back.

Answer 5

Another option for really long lived changes that may be finished but not ready for use is to put them behind a feature flag so they can be merged in to master but have no risk of breaking anything. Then when they are ready to be used the feature flag can be removed.