I find the exact opposite to be true.
When you merge 20 commits from a branch, you add to the history a bunch of unfinished-state checkpoints, which may not even compile individually, and that may make the search longer than it should. Also, those intermediate commits probably never were deployed as individual units.
In a merge-squashed main branch all commits:
* were reviewed as a single unit, but may have originated from multi-commit branches
* are guaranteed to have passed the test suite
* by definition, are at a ready-to-deploy state, even if they contain feature-flagged components
These are much easier to bisect through. And their changeset shouldn’t be any larger than any regularly-merged branches. It’s the same unit of work, merged differently.
If the PR is too large, then you’re probably lumping too much stuff together, which also leads to slower and worse code review cycles.
In my team, we merge squash our PRs, having a guideline that they should be a small increment. Here's what happrns:
- when you checkout a commit, you are guaranteed to have a version that was reviewed by a person and validated by ci/cd - most commits have chsnegs with substance, instead of "log", "debug", etc
Without squash, a person can push 3 commits to a feature branch, ci/cd says the last commit is OK, it gets merged, and you may get 2 commits that don't compile or cause a very basic runtime error due to some typo or whatever.
(not that it could not be solved with due diligence, but that comes with higher effort too)
How do you assure working commits and avoid noise without either squash or rebase?