4 ms·
> why do you care about my 10 "wip" commits on a feature branch? If that's how a team develops PRs, then the commits are structurally suboptimal, and the probl
by pizza234 4y ago
> why do you care about my 10 "wip" commits on a feature branch?
If that's how a team develops PRs, then the commits are structurally suboptimal, and the problem is in the development practices.
Such team won't be able to efficiently bisect, independently of the repository structure.
I personally work with granular, self-standing commits, and with this workflow, non-squashed commits makes sense.
Obviously it's not possible to always have self-standing commits, but it is possible the vast majority of the times.
It takes a lot of practice and discipline, though, and if a team is not willing to put them, then of course, squashing in the only way that makes sense.
- samus 4y agoWhy would I want to bisect on a feature branch? Edit: I strive to keep my feature branches both short (# of commits) and light (# of lines changed).
- pizza234 4y agoAfter a feature branch is merged, its content is candidate for any bisect. If the branch was squashed, bisecting will be less effective, compared to the same branch, merged without squashing (at the conditions of the commits being self-standing).