It's definitely better than having a bunch of garbage "wip" commits, but it's still far from ideal in my mind. In your world, you'd git bisect and eventually en

It's definitely better than having a bunch of garbage "wip" commits, but it's still far from ideal in my mind. In your world, you'd git bisect and eventually end up in a 300+ line diff. > You want to split it in multiple commits? Then it probably should have been split in multiple PRs . This can be inconvenient and slow down development. I still prefer to just interactively rebase and squash commits locally before making a PR. Then ideally I'd like a rebase + merge commit (which unfortunately Github doesn't support in the UI). Then you can git bisect with --first-parent to find which PR caused the bug. Maybe it was small enough that you don't need to dig deeper, but if you do, you can bisect the individual commits (something that would be lost if you squashed). But like everything in our business, it's a matter of trade-offs, team experience, priorities etc. When I was younger, I was very opinionated on this stuff, now I just go with the flow.