Should we squash commits if we rely on git bisect to find regressions?

Choose a merge policy that preserves your smallest reliably runnable unit: individual commits when each is tested, or a squashed pull request when only the combined change is runnable. git bisect works by checking out commits between a known good and bad point until it finds the first bad commit, so its usefulness depends on what runnable units your history preserves on the mainline. Squashing is fine when the whole pull request is your smallest tested unit, but it removes intermediate troubleshooting evidence that can make regressions faster to localize in practice. Git’s own documentation says git bisect uses a binary search to find “the commit that introduced a bug” and repeatedly asks you to compile and test the checked-out revision (Git bisect documentation).

What runnable unit do you want preserved on main?

That is the real policy question. With squash merge, main preserves one commit per pull request. With a regular merge commit, main preserves the branch’s individual commits and the integration point. With rebase-and-merge, main preserves individual commits but not the merge node.

If every commit in a branch is buildable and meaningful, preserving them gives git bisect more resolution. You can identify not just which pull request introduced a regression, but which commit inside it did. If branch commits are frequently broken, noisy, or “WIP”, keeping them on main makes bisect less reliable because the tool will stop on states your team never intended to support. In that case, squash can be a better fit because it defines the pull request as the only supported, testable unit.

Does squash merging make debugging regressions harder?

Yes, when the useful evidence lives inside the pull request’s intermediate commits. Squashing collapses that sequence into one result commit, so git bisect can only tell you that the regression appeared somewhere in the PR-sized change. You still have the pull request discussion, but you lose the ability to bisect across the branch’s internal steps once they are not part of main history.

A normal merge records “a new commit along with the names of the two parent commits,” preserving the branch topology and commit sequence (Git merge documentation). That preserved structure helps when a regression came from one refactor commit while a later commit in the same PR only updated tests or docs.

What policy works best in practice?

Use this checklist:

• Choose squash merge if the pull request is your smallest guaranteed green unit.
• Choose merge commit or rebase-and-merge if individual commits are expected to compile, pass tests, and tell a coherent story.
• Do not preserve broken intermediate commits on main just to get finer bisect granularity.
• Require CI on the unit you preserve, whether that is each commit or the final PR head.

Worked example: a PR contains four commits—schema change, application code, test fixes, and cleanup. If each commit passes independently, preserving them lets git bisect land on the schema change directly. If commit two fails until commit three arrives, squashing the PR may be better because the only runnable artifact is the combined result.

What should the team verify before adopting this workflow?

First, verify your enforced boundary: is it “every commit on main is runnable” or only “every merged PR result is runnable”? Your merge policy should match that boundary, not fight it.

Second, test the workflow with a real regression drill. Run git bisect across a known bad change and see whether your current history gives answers at the level you need.

Follow-up Q&A:

Should we ban squash merges entirely? No. Use them for branches with cleanup noise or dependent commits that are not independently valid.

If we keep merge commits, do we need every branch commit polished? Not polished, but each preserved commit should be buildable and interpretable enough that bisecting through it is worth the cost.

Next step: decide what your smallest supported runnable unit is on main, then set your repository merge policy to preserve exactly that unit.

Reviewed: 2026-09-05