How to organize the work so that some commits - others resolve conflicts?

Question

git

In general, I want to organize the work of lvl designers. But at the same time, I would not like to dedicate them to ways to resolve merge conflicts. Even if it would be possible to train them quickly, I don’t even want to trust this business to them, so that later I can look for the reason for strange errors)
I want them to just use the pull-push options and that’s where their role ends. I want to resolve conflicts myself.

Any ideas:

• The lvl designer works in a separate branch, I merge their branch into feature, and then vice versa (I feel cringe).
  
• The option is similar to the previous one, but I ask the designer not to work , I rebase his branch (yes, public) relative to feature. Well, then he pulls the changes and continues.
  

Is any of this adequate/are there any other options?)

Answer 1

I'm not a git guru, there are probably easier ways, but how would I do it: I would create a separate branch for merge request (give the designer a simple script for this).
Those. there is a branch dev, the designer makes his own branch from it featureas usual, then when it's time to do MR - another branch is made by the script from the featureconditional view feature_to_dev_<date>, and MR is already made from it dev, then:
a) there are conflicts - a notification is sent to you, you correct conflicts and merge,
b) no - automerge and delete.
In any case, the designer at this time continues to work quietly in his feature.
back devtofeature, if necessary, the designer pours in through a simple MR, and if there are conflicts, he pokes you, there’s no way without stopping work. But, in theory, there should not be frequent conflicts if his work was regularly poured into dev.