This might be just a stupid idea, but I think that the best "conflict resolution" can be achieved by avoiding them in the first place, so here's my 2cts:
My approach (luckily I do have exclusive locks), if I'd have to work without locks:
1) Refuse! Tell my bosses to buy Gitlab Premium. Merge is something to avoid and takes up time and can introduce errors. Before buying, I do recommend to investigate how / if these locks would work with PB. There's (been) quite some bugs with "normal" Git already.
2) Depending on how many Developers might work simultaneously in a same project. I would write some kind of small program / webpage in which all objects are listed.
Before doing any modifications you would:
- Find the object and see if anyone is working on it.
- If free, mark it as in use by you (your name) and maybe some description
- When done with the object and checked in/synced with Git, erase your information from that little app so others can see it's free for editing.
Maybe that's a bit of a hassle but way less hassle than having to merge all the time and wonder which changes prevail over others. Depending on the amount of objects to merge, that process might take up a lot more time. You have to know why someone did a specific change, even when it was 2 months ago, .. .oh he's sick, oh she's on a holiday, oh no longer works here, etc. Or you make the implicated developers get together and do the merge together (if possible).
Of course this would only work if everyone follow the rules strictly, even when doing small and fast changes.
Another way of reducing the need for merges, would be to divide different work to different people to reduce the possibility they'd clash in their need for objects to be modified. Have someone special for doing changes in common/ancestor objects and don't allow others, etc.
Division of work. I also think that's a bit what DevOps is about in a way, though I still don't see how that "thing" is anything else then Agile with a new suit, (and that's because I'm ignorant about DevOps).
Git might do a good enough merge of the other objects.
As a manager / team lead, I always checked the "lock" queue report in my SCM a few times a week. Then compared that to what I thought the developers were working on. Comparing the previous weekly locked object report as well to find out why the code was still checked out too. That gave me a good excuse to also to use my MBWA (Management By Walking Around) approach. I always used a "polite" approach ... Hi Judy / Bob, I see that some of your code is still checked out. Are there any difficulties that I can help you with. Quite often, that allowed me to help developers that were struggling with a certain enhancement. ;-)