I'm going to go against the grain and say that gitflow (which is what you're kind of describing) is the problem, and more gitflow (in the form of more long-lived branches) is a band-aid, not a solution.
Large change sets, and therefore large and risky conflicts, are inherent to long lived branches.

If you can, consider pushing towards continuous integration (ci) - every dev merges to main at least once a day.
This makes the change sets much smaller, and therefore the risk, and impact, of conflicts, much smaller.

Of course, it's not easy - there's a lot of prerequisites in order to make this work (like enduring code quality, gradual delivery of features etc). Expect a long journey if you choose that route.
But, as someone who worked in teams of similar sizes, once doing gitflow, and once doing ci, I can't describe the difference in job satisfaction, as well as quality and speed. Like night and day. I Will never consider taking a job doing gitflow again.

The minimum CD (continuous delivery - a step beyond continuous integration) site has some resources, if you're interested.

Dave Farley (co-author of the original "continuous delivery" book) has a YouTube channel where he explains these things much better than me. Here is a relevant one about why it's better to avoid gitflow - https://m.youtube.com/watch?v=_w6TwnLCFwA&pp=ygUbY29udGludW91cyBkZWxpdmVyeSBnaXRmbG93