3 ms·
>- are easier to debug (and possible to bisect; it's not possible to bisect a squashed commit). In practice, if bisecting indicates a commit caused the problem
by jaredsohn 2y ago
>- are easier to debug (and possible to bisect; it's not possible to bisect a squashed commit).
In practice, if bisecting indicates a commit caused the problem you can narrow it down further by checking out that branch and investigating further within that branch (which ideally isn't too large). Also, if you have a highly structured PR then you may need to be careful to ensure that each individual commit passes CI.
At that point you might as well ship each commit via a separate PR. (While in development you can temporarily set the branch for Part 1 as the base for Part 2.)
- fouc 2y agoYou're assuming it is not an old bug and that the branch is somehow kept around for other developers to re-open months or years later. A PR for each commit seems overkill. Usually a PR is for a feature, but code-wise, a feature might require several atomic changes. For example: prepare configuration, move files around, add tests, add new code, delete old code, refactor. Each of those could be a separate commit, bringing you to a polished feature with test coverage.
- jaredsohn 2y agoMight depend on how companies use git but I just verified I can see commits for PRs from 2017 in my work codebase; could bisect that if needed (although code likely is no longer relevant.) I think splitting PRs into multiple commits can make sense when there are only 2-3 commits but you're right that it doesn't when there are more than that.
- pizza234 2y ago> At that point you might as well ship each commit via a separate PR. (While in development you can temporarily set the branch for Part 1 as the base for Part 2.) Absolutely. Indeed, this (independent commit) is a very positive side effect (typical example: separating refactoring commits).