A team simultaneously made several refactorings (to raise system genericity) to the same project with some overlaps (yes, unfortunately, more like "big bang"). Code is spanning representation, application, domain layers and has pretty high code coverage. There are N branches waiting to be merged into the master. Some refactorings were more into representation, but most of them were in the domain, with some overlaps (ok, there are changes to model's central and most-used entities: two entities merged, one broken down into two plus completely new one added).
What could be good order to merge the branches? Should the team start from lower tiers up or the other way around? Or maybe branches with less "footprint" should be merged first?
Gut feeling is to merge lower-tier-focused branches first, then go up. What other things are there to consider to bring redundant work to the minimum?
If it matters, most feature branches were derived from master at almost the same time and kept readily mergeable to the master.
Surprisingly, I have not found any theories or good reflections on the subject. I've tried to ask the question in a more general way in hope that the answer will also contian more generic heuristics and list of relevant considerations, so it will be more useful than just specific situation.
De facto, granularity of commits differs between developers. Sometimes, commit is done for broken code to make others take a closer look.