You don’t. One of the core aspects of Git is that it fully expects conflicts to be inevitable, and it gives you tools to resolve them.

I will say that if you learn to aggressively rebase branches, you can at least occasionally reduce the complexity of conflicts.

If you are working on a long branch and three other branches that conflict with your changes land in the meantime, a simple merge will force you to reconcile all of those conflicts in one big stinky merge commit.

If you instead rebase after each individual branch lands, you resolve the same number of conflicts but in three smaller, focused steps instead of one big ugly one. You also don’t get a merge commit full of redundant deltas that serve only to resync your branch to master; all the conflict resolution becomes baked in to your individual branch commits.

Spreading out the problem is not reducing the problem. But it can make fixing the problem less daunting, which has a similar effect.

It’s kind of difficult to explain in the same way git is difficult to grok on the first try.

Perhaps it’s convincing enough to just say:

• Git is the fundamentally better at resolving merges/rebases without conflicts than older VCS that don’t maintain a commit tree data structure.
• Even within just git, using one diff algorithm vs another can mean the difference between git successfully merging vs failing and showing you a conflict
• Software is flexible – there are endless permutations to how it can be structured. Everything else being equal, some code/commit structures are more prone to conflicts than others

I.e. whether a conflict will happen is not some totally unpredictable random event. It’s possible to engineer a project’s code & repo so that conflicts are less common.