TLDR: avoid millions of Merge branch master into xxx commits on a busy project, keeping commit history clean, and allow reverting merged branches easily.
In case this helps anybody else:
I had always understood rebase as a mechanism that replaces merging a feature branch onto master, that allows you to squash all the 'messy' development commits on the feature branch, onto a single nice clean commit on master. In this model, you can be as messy as you want on the feature branch (with 'whoops bugfix' commmits and lots of merging in), and the feature branch is generally short-lived -- once you rebase+squash it onto master, the feature branch gets deleted, and you start a new one if necessary for further work.
The proposed model is the opposite -- you try to keep a clean feature branch. Every time you want to fold in changes from master, you do it as rebase, which has nothing to do with squashing anything -- it's about bringing forward the starting point of your feature branch to match master's current state. Then, when it's time to bring feature into master, you merge, not rebase, so the branch history is preserved, it's just nice and clean. And I suppose you can keep the feature branch around for more work on it, so it's almost more of a long-lived 'topic' branch with a bunch of individual features stringing along it.
The funny thing is, I've never seen a blog post that talks about both kinds of rebasing at once. Every one I've seen seems to look at it from one viewpoint or the other, which it possibly why rebasing can get so confusing (maybe I've missed one that does explain it well, both ways). The "git-scm" site describes the first way, but this blog post helped me understand this other way of rebasing:
http://blog.marcomonteiro.net/post/are-you-a-merge-or-rebase...
Thanks!
You ARE right, that before such a merge, it's a common practice to squash your commits on the feature branch to clean it up and then merge a single commit over to master. (To squash you use git rebase -i but you're squashing not rebasing).
If you were to actually rebase this branch into Master instead of merging it, it would change the commit hashes for commits already in master, leading to awful merge conflicts the next time a teammate tried to pull down your changes.
I wanted to mention this to hopefully connect the last few dots. The reason most articles don't talk about "both" these ways, is because really there is only one way, with a few different choices.
Maintaining a branch: If you need to bring changes from Master into a long-running branch, you can either do so with merge or rebase. Rebase is cleaner IMO.
Preparing to integrate your work into master: You can either squash some or all of your commits, or you can keep the history as-is.
Integrating into master: You always do this with a merge.
http://git-scm.com/book/en/Git-Branching-Rebasing
So I guess I'm starting to see how these are somewhat the same thing in the end, just from different perspectives. Thanks again.
For squashing into a single commit, you can even use
git merge branch_name --squash