I think the best point of this article is accidentally introducing breakages into history that later defeat the purpose of git-bisect. However, in practice I ha

I think the best point of this article is accidentally introducing breakages into history that later defeat the purpose of git-bisect. However, in practice I haven't run into this problem, at least not in an insurmountable way. One solution is, if you can run your tests with e.g. `make test`, you can run `git rebase --exec "make test"` which will run your test suite against every commit being rebased. I've only done it a handful of times, and because of how long it takes I'd only run it after finishing a rebase that wound up needing resolutions, instead of doing it up front and having to wait for the tests to finish at each commit before potentially resolving another upcoming conflict. If you are very paranoid about breaking commits being pushed, disallowing rebase isn't enough: any dev could simply write a commit with a breakage. You'd have to set up pre-commit hooks to run your tests, or a pre-push hook to run `git rebase --exec "make test"`. TIL there is also a post-rewrite hook, which sounds like it solves exactly your worry with rebase, but as I mentioned, introduces long delays between rebase commits/resolutions–I'd probably forget what I was doing during each test run, haha.