This is one of those cases where the solution seems difficult, but the difficulty is in the problem itself, not the solution. The source of the conflicts is the

This is one of those cases where the solution seems difficult, but the difficulty is in the problem itself, not the solution. The source of the conflicts is the fact that you work with multiple people, in a distributed way on the same codebase. Those conflicts are going to arise one way or another. Git could tell them to you beforehand, but that would be just the same as rebasing and then aborting. The conflicts stay the same, no matter how you slice them. In my experience best is to coordinate with other about code changes to avoid conflicts altogether or to fetch and rebase often to keep conflict scope to a minimum so they are more manageable. Also keeping commits focussed on single features/changes instead of spreading out the feature over multiple work in progress like commits so they can be applied as a standalone change helps. I really learned this when working in Gerrit Review for a while. Where there is no one pull request for a branch full of commits, but each commit is a change applied to master on its own and has to be reviewed/tested as such. Git is not a magical tool that solves all collaborative coding problems, but more a toolset that helps you manages code changes. You definitely need to put some effort into the mental model of how to manage changes before you can use the toolkit to its full potential.