I am not trying to put myself out here as an expert; far from it. Rather, I wanted to share how I've been doing things and seeing if people think, "yeah, that's pretty much it" or "no its totally wrong".
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.
I think all organizations end up protecting their branches at the CI level to completely shut down on rewriting past history. It just makes no sense in most cases.
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,
> it also means the feature being worked on is becoming too big/too much in conflict to be kept alive separate for long
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.
Your colleague’s approach is nice. The only warning would b e on losing meaningful grouping of work.
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.
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.