One difference is that instead of fetching and rebasing changes from origin straight into your topic branch, we recommend checking out master, pulling in changes, checking out your topic branch and rebasing against master. This way master is also up to date.
As for the .gitconfig tip near the end, I don't think changing the behaviour of such a common command like pull is a good idea. Better to be explicit.
This is exactly how I do my git stuff. The only thing that I don't like about this is that you need to force your push after you rebash with master as you have noted. Also what solution do you use when you are sharing your feature branch with other people (especially with 1-2 other programmers) while still rebasing off master?
> Also what solution do you use when you are sharing your feature branch with other people (especially with 1-2 other programmers) while still rebasing off master?
We don't have that problem because we keep topic branches personal (but still public so they can be reviewed). In other words, our topic branches branch off from master, we don't branch off of someone's topic branch to build a new feature on top of it while the current feature is still ongoing.
We try to make branches short-lived and break larger tasks into small parts that can ship individually.
One difference is that instead of fetching and rebasing changes from origin straight into your topic branch, we recommend checking out master, pulling in changes, checking out your topic branch and rebasing against master. This way master is also up to date.
As for the .gitconfig tip near the end, I don't think changing the behaviour of such a common command like pull is a good idea. Better to be explicit.