Just....don't.
Don't use GIT.
Use WizSource. Keep it simple, clean, easily integrated with PowerBuilder, and inexpensive.

Olan

I agree with Miguel it is best to change practices to try to avoid.  Of course, sometimes it will happen and the tools for Git are usually good at resolving conflict resolutions. 

Bruce has done quite a few presentations on this topic, and if you haven't watched them I recommend at least watching his Git Bootcamp and carefully following his suggestions: https://www.appeon.com/developers/library/videos/git-bootcamp.html

Also, as Bruce mentioned in this presentation that there is versions of Git that do allow you to lock if you really want to work in this way.  For example, the on-premise GitLab Premium and Ultimate editions support file locking: https://about.gitlab.com/pricing/#self-managed

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).

NO! (ref: Stack Overflow)

You will need to lock the whole branch. Git's problem is that it is distributed. No concept of central repo to manage locks.

Very few git implementations add file locking. One of them is GitLab Premium.

HTH /Michael