I think at scale, merges are too problematic, however for a long time I worked on a (small) team who took the approach that got history should represent “what y

I think at scale, merges are too problematic, however for a long time I worked on a (small) team who took the approach that got history should represent “what you actually did”, and the thought process behind that, rather than the “perfect ideal” of the changes being made. This brings its own benefits, it is often easier to learn from the commits, it’s often easier to review because you have more granular commits and can follow a dev’s thought process. And if you’re doing post-merge review as we did in the early days, you don’t lose that granularity when squashing. A nice bonus was that because there was no rebasing, no one ever really “broke git”, a classic issue for more junior developers. Ultimately the approach didn’t scale beyond ~8 devs/~500k lines/~15 PRs a day, but it was good for a long time. The important thing though is: have a git style guide, make decisions for reasons that matter to your team, and stick to the style guide.