The most valuable feature from rebase to me is, that the one who commits to a feature branch, also "merges" the branch to the current master. So right after you finish your work on a branch, you can rebase even before having it reviewed by another person. When it's good to go, the actual merge is fast-forward.
That's exactly it. In one sense, it's just a better, less annoying form of merging. You get to sequence your commits on top of the current upstream (literally re-basing) without a merge commit that makes little sense in context. Then the ff-merge to master is also clean. I don't understand why anyone would be against this.
It's not that anyone is against it when it's possible to do it cleanly. But there are cases when that isn't true. Sometimes the branch is not ephemeral, so rewriting it becomes messy and risky.
I frequently find myself fixing or extending some open source project that my own systems depend on. Usually upstream will eventually take the patch, sometimes they might not. But I can't wait around to find out -- my own "master" branch gets deployed and lives a life of its own.
When upstream does get around the merging the changes, and I pull from upstream, the merge is 100% safe and clean because git sees my own commits coming back again. But if instead the changes were rebased, the chain of history is broken and git needs to go into conflict resolution mode. If I've changed other things since, I get a mess.
All of this gets even worse if you have things like continuous integration servers and git-based deploys. Those systems will happily deal with merges and break when you go and rebase a branch they've already seen.
Actually, I think the article's point was that big feature branches should be merged --no-ff so that they would not be a fast forward commit. That way you can whack them out of master easily if needed. You can still rebase right before the merge -- I would.
