I can understand they don't want to oversquash - I rebase & squash so that each commit should be able to stand on its own. I think the above link is a good argument for squashing (and rebasing) to the point that each commit should leave the system in a state where everything works, because otherwise you can't use `git bisect` and actually determine if it's good or bad. I will often have more granular commits where I break something and then fix it in the next commit.
Yeah, I think you're asking for trouble if you start squashing commits on code that has been deployed, which is the situation he seems to be describing here. I can't see any net benefit to that, and can see a whole lot of trouble. Any time your code has been shared outside your personal development environment, rebasing is dicey. The only situation I can think of that validates that is if something ended up in a commit that definitely should not, like auth credentials.
> The only situation I can think of that validates that is if something ended up in a commit that definitely should not, like auth credentials.
Even then, you can't unleak auth credentials so you will need to change them anyway. Then leaving the commit, while embarrasing, is no longer an actual issue.
Given most teams operate CI pipelines on their PRs/MRs, I like to make it a requirement to squash before merging. This means that only passing builds make it into the main branch.
The value of this cannot be underestimated, in my experience, as using things like “git bisect” mean you always have a working build.
I can understand they don't want to oversquash - I rebase & squash so that each commit should be able to stand on its own. I think the above link is a good argument for squashing (and rebasing) to the point that each commit should leave the system in a state where everything works, because otherwise you can't use `git bisect` and actually determine if it's good or bad. I will often have more granular commits where I break something and then fix it in the next commit.