Merging rocks! Never had an issue with merging and it’s less work. I’d only rebase if there is a “story” I want to tell in the commit history, that would be otherwise lost. This is rare, probably if someone else did some major refactor or move around
It only makes a difference if everything is fast forwarded onto master. If branches are squash merged in (as is common), keeping those merged in branches up to date via merges or rebasing doesn't make much difference to others.
If you are chucking all your commits onto master - power to you. That's probably a good pattern (I prefer as much historical data as possible to a 'neat' commit history), but I never see it done because usually master is linked to CI and the idea is is every commit to master should be a valid build.
Master or any branch you're aiming to integrate into.
Squashing everything is bad because it makes code review and backports harder. Maybe you don't care about backports, but if you care about code reviews...
Honestly I just diff the whole thing from where they branched to the tip anyway I rarely find the individual commits useful as there is usually a process of their discovery in that with backtracks etc. that’s a waste of time to review.
For example I could review a new class that they heavily refactored in the next commit.
I’ve not had an issue with code reviews or backporting. I suspect this is because either out units of work are smaller than usual (no long feature branches)
But maybe you are onto something here and I’m missing out on a better way but I’ve not experienced enough pain in squashing on merge to master to contemplate switching to a rebase workflow (which means convincing
team members too)
