5 ms·
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 i
by echlebek 9y ago
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.
- hdhzy 9y agoUhm, changing published commits is not recommended in git, maybe except private repos or branches. Could you point to specific workflows that encourage this?
- geezerjay 9y agoI 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.
- ZeroGravitas 9y agoI 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.
- theknarf 9y agoSome 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.
- marcinkuzminski 9y agoThat'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.