Rebase vs Squash -- I very often find myself having to look at the code and understand the relationship of all the changes, why they have been done like that, what depends on what etc. For bisecting, when you are hunting a bug and you end up in a big commit, now where's the bug exactly? Personally I've always used that model, even before Github, if you mean developing a feature in a separate branch that can be eventually squash merged into a single commit or rebase merged in multiple commit. My point is that the whole reason in git of making commits as small as possible is readability and ability to point to a "small" diff and say "this is what broke everything". Or this is what it's implementing X. If you have big diff, you lose a very important feature imho. I mean there are cases where you need to touch/adjust multiple places to finally add the feature you want, and those touches and adjustments are not small. Each of them can be translated into commits that can stand on their own (as in, everything builds and doesn't break any present functionality), but they do not make sense alone, they need an overarching theme to explain why they exists, "implementing feature X". Or they can all be squashed into a single mega commit and a single PR made out of that. But that diff is not readable, so the alternative would've been making multiple PRs for each of those commits; though again each of those PRs wouldn't have made sense without knowing "this is for implementing feature X". And so, even if you linked all the PRs together, so that you could track what was the end goal, or Github had a "sub-task like" feature, you still would've ended up with multiple commits in git; exactly the same as with a rebase merge, though now with multiple PRs to chase through.