I'm a big fan of PRs/comments on GitHub as well (although they do raise some data ownership issues). Squashed commits are interesting, but not something I've u

I'm a big fan of PRs/comments on GitHub as well (although they do raise some data ownership issues). Squashed commits are interesting, but not something I've used personally in GitHub. I think squashing, especially automatically, has big tradeoffs. It's nice to have a cohesive unit of change in a single commit, but if your mergeable features have a lot of moving parts it may be too much information in one giant blob, losing valuable history. There are certain things I like to be in individual commits, like for instance, DB migrations in Rails or Django, or Gemfile/Gemfile.lock upgrades. Having these in separate commits allows for easier conflict resolution later, and are also a nice granularity for practices like zero-downtime continuous deployment where you need to have multi-phase deploy of migrations (ie. phase 1: deploy migrations that add fields, phase 2: deploy code that requires new fields, phase 3: remove fields required by legacy code). Maybe in a large team with a large volume of PRs then squashing by default is preferred so you can make sense of a fast-moving history, but given that it's so easy to squash selectively with `git rebase -i` that is my preferred method, at least for the team I'm on now.