My linked git-branchless tool will tell you before a merge conflict occurs, so that you don't have to abort it, although it could produce more information about the impending merge conflict.
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.
It will let you know in advance if conflicts will occur when merging another branch or revision (by merging, rebasing, or pulling). Here's an example: https://imgur.com/a/VCkqrBI
You can learn more about Tower's Merge Improvements here https://www.git-tower.com/blog/tower-mac-9/#1-merge-improvem...
I hope you give Tower a try!