Considering the Philosophy of Git Squashing
quentb.com
quentb.com
For the record, I understand and empathize with the camp who responds "well, you shouldn't be squashing/rebasing at all; all git activity should be a commit or a merge." I am operating in the context where the main branch's commit history must be linear -- it is a customer/manager constraint. I hope to discuss options inside this paradigm.
On how individual devs deal with that, the alternative to the massive squashing is to me cherry-picking one’s changes against the upstream.
The bigger the branches diverge the more of a PITA it is to herry-pick, but it also means the feature being worked on is becoming too big/too much in conflict to be kept alive separate for long. My own target is 3 to 4 meaningful commits per-branch, excluding MR comments, and it works fine, mostly,
That's a really great point and something a colleague pointed out to me when I was musing about this.
Another coworker told me they like to do commits + occasional merges from upstream into their feature branch as normal, then when they have built up a lot of commits, use `git reset --soft master` and then git add/commit all changes as one commit, with a nice verbose commit message.
I really like that approach, if you have to do it.
For instance if you are doing a change in two clear steps (e.g creating a new module first, and switching existing behaviors to the new module in a second time), having separate commits helps for readability, but also if you end up needing to split your branches in two or more.
In particular it makes a big difference if you happen to need to revert: you’ll probably get away with reverting one of the commits, instead of the whole feature.