Interactive rebasing with fixup/squash makes the end result very readable. `git reset` and `git add -p` can also be a huge boon when tidying up a branch before PR.
Interactive rebasing with fixup/squash makes the end result very readable. `git reset` and `git add -p` can also be a huge boon when tidying up a branch before PR.
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.
IMO this is classical example of "don't solve the administrative tasks with technical means". Git is a tool, how do you use it is up to you.
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.
The value of this cannot be underestimated, in my experience, as using things like “git bisect” mean you always have a working build.