@marnen you're right and you're wrong. There's nothing wrong with rebasing a topic branch that only you've worked on to squash it down to change sets that actually make sense and/or to rebase it on top of master before sharing it with others. However, if you really don't want to have a pull erase a merge you've made, then you're right, you shouldn't be doing git pull --rebase. Keep master clean until you're ready to push. This means don't run git merge --no-ff mybranch until you've just run git pull on master. If you didn't do that, then fine, but still don't run git pull --rebase, just do a normal git pull and you'll have an extra merge commit, but that's kind of what you asked for.
@marnen you're right and you're wrong. There's nothing wrong with rebasing a topic branch that only you've worked on to squash it down to change sets that actually make sense and/or to rebase it on top of master before sharing it with others. However, if you really don't want to have a
pullerase a merge you've made, then you're right, you shouldn't be doinggit pull --rebase. Keepmasterclean until you're ready topush. This means don't rungit merge --no-ff mybranchuntil you've just rungit pullonmaster. If you didn't do that, then fine, but still don't rungit pull --rebase, just do a normalgit pulland you'll have an extra merge commit, but that's kind of what you asked for.