If your PR is big enough that you're relying on a git bisect to find a bug, that's a problem in its own right.
A workflow like what OP is describing (code doesn't exist until it's merged) typically also assumes that your PR is one atomic change, not a whole feature. You'd use feature flags or something similar to decide when to actually release a feature, not the PR process.
> If your PR is big enough that you're relying on a git bisect to find a bug, that's a problem in its own right.
Who said anything about bisecting?
But yes, sometimes changes are big and I'd rather land them as one cohesive unit that demonstrates how it actually solves the root issue than get stuck down a wrong path because "this is what we already landed the infra for".
> A workflow like what OP is describing (code doesn't exist until it's merged)
That's not a workflow, it's a misunderstanding of reality.
