I see your points, but I disagree. FWIW, I also adopted the squash-merge only strategy with no regrets. > Squash merge has the major disadvantage of getting r

I see your points, but I disagree. FWIW, I also adopted the squash-merge only strategy with no regrets. > Squash merge has the major disadvantage of getting rid of valuable meaningful git history. It's not lost, at all -- it's in the branch it was squash-merged from. The point is that the topic/fix/experimental branch will likely have lots of history, including discarded ideas and other 'meanderings'. Every commit in that branch is meaningful in that it was a discrete step in that path. But, eventually what is _finally_ in that branch is what is relevant when merging to master. All that extra history in master would create confusion (and has for many in projects I've worked on). If the discipline is that every commit must be a meaningful, viable point _in master_, then a merge of the history would make sense -- but I've never seen that possible (or even desired) in practice.