> no need to squash unless you split trivial changes that belong together If a PR represents a distinct product feature/bug fix/unit of work, one could argue t

> no need to squash unless you split trivial changes that belong together If a PR represents a distinct product feature/bug fix/unit of work, one could argue that its commits belong together. Squashing makes for a very clean history. True it reduces granularity, but in my opinion at least, it's a good level of granularity. The exception to this would be a really big PR. That's a reason to avoid huge PRs.