The idea behind feature branches is they should only contain a small, atomic change. This change should, in theory not cause merge conflicts due to its very nature.
If a feature is introducing merge conflicts I would be more inclined to examine what you consider to be "a feature".
The way I have experienced this being introduced is that a feature relates to a specific task which (in terms of time) should last no more than one or two days.
Given this short timescale it is unlikely that merge conflicts will arise during the cycle but in the event that they do, say for instance when you have multiple teams working in the same area of a codebase, a level of communication is required to ensure that the conflicts are resolved in the correct manner.
There are different models you can apply to help you manage conflict resolution. We work on a horizontal slicing model in which if multiple teams need a change to be made in a particular area of the codebase it is assigned to the team whose project encompasses the whole of that given module. Your company may be more interested in a vertical slicing model in which case you're less likely to run into merge conflicts across teams.
No amount of tooling can beat conversation for conflict resolution. If you know that your changes are going to impact a file that someone else is working on, the best model to follow is a conversation.
In some situations this will not be ideal, the business might have other ideas about whose changes go out when but as long as every developer keeps their feature branch up to date with develop then the propensity for conflicts is greatly reduced.
