IMHO it’s not so much a Git issue as a workflow issue. Typically, I solve this with CI and Pull Requests. You see, in GitHub, GitLab, etc. any “merge intent” solidifies as a Pull/Merge Request. The hosting service then first tests the mergability, which is pure-code, and won’t detect functional breakages.
But if you have CI hooked up (Travis, CodeShip, etc.), the CI will run your test suite on two sets: (1) the branch head itself and if that passes (2) the potential merge in the recipient branch (usually master). So the PR gets cleared for merging if and only if the resulting merge also passes your entire test suite.
Which clears a lot of issues. Provided you have sufficient test coverage ;-)
At any rate, if no bug is caught even then and you later realize the source branch was faulty and therefore its work unfinished, you have two options really:
- Undo the merge, get back to work on the source branch, then merge again later (to retain a single merge point). This is often cumbersome or hardly feasible.
- Start your branch “again” from the current master, fix on it, and merge again later. You could just git checkout -B oauth-signin master for instance, and get going. True, the branch ends up as “multiple bumps” on the graph, but the default names of the merge points (“Merge branch oauth-signin”) helps figuring out the whole history anyway, and that avoid an even uglier-looking graph if you resumed work on the branch from its legacy head.