You can avoid this by branching by abstraction instead:
Summary: Don't separate differing concerns by using a VCS, use an abstraction instead.
If you start branching in VCS for regional differences, where most common example would be to branch by language or country, you will start to slip into the slippery-slope known as variant management. This is because managing variants through source control itself is a very unmanageable practice, because they can grow into an unmanagable number really quickly.
Let me repeat this:
MANAGING VARIANTS IN VCS IS A HORRIBLE PRACTICE AND LEAVES YOU WITH A TECHNICAL DEBT OF EXPONENTIAL PROPORTIONS!
So what do you do instead? Well, you don't use VCS for branching variations; instead you build the variation support it into your application through abstraction. In your case the application varies in regions, so why not make that what varies into pluggable modules into your application? Or even simpler: have a configuration file for each region that the application would load and use the features needed for the configured region. It could all be checked into one and same branch, instead of bloating it all into several branches.
Here is an anecdotal and hopefully practical example of branching by abstraction:
In one of my previous workplaces website has support for many countries in europe (that has different languages and needs). We had a nifty feature blocker in place where new features would be registered into a feature access list. It initially started out with only logged in developers and testers would have access to the unreleased features. Later we would add checks on countries and languages such as logged in users in the correct region could access the feature.
This way we could quickly push out new features or quickly halt them in production if we ever needed to do that. No need to merge because it is handled by the application itself.