As a former mercurial user, it absolutely drives me nuts when people rebase already-pushed commits. I get that this is the norm in a lot of git workflows, but it still makes me twitch!
I prefer to rebase liberally before pushing commits, and then merge once commits have landed in a shared repo or been pulled by others. No git --force necessary.
Uhm, changing published commits is not recommended in git, maybe except private repos or branches. Could you point to specific workflows that encourage this?
I assumed the standard rebase practice was to rebase only local branches, and only if you intended to continue working on a feature branch over updated versions of your target branch without introducing superfluous merges. Consequently, although I've been using rebase for a couple of years now I never had to use git --force to handle a rebase.
I only sometimes use force because I "share" the branches with the automated CI system so they are not strictly local and may need force pushed after a rebase, but no other human will be inconvenienced by those pushes.
Some git hosting services let you turn off the ability to accept force-push. Github and Bitbucket both support this. That's usually the first thing I do when setting up a shared repo for a project.
That's where Mercurial phases and publishing repositories improve UX a lot. Developers can have their forks with non-publishing repositories that indicate commits that are not in public state and can be easily edited. This is such a great concept.
Good one, everyday I have to explain one of my coleague engineer why he should not just take a shortcut and merge it, rebase it instead it could be bit painful to resolve the conflict as we continue to rebase but definately cleaner.