Only You Can Prevent git Merge Commits(viget.com) |
Only You Can Prevent git Merge Commits(viget.com) |
Anyway, "git pull --rebase" is your friend. (And so is "git push --force". git pull will DTRT on the other end, so this shouldn't mess anyone else up.)
'--force' overrides this check, pushing anyways, effectively losing (possibly multiple) commits on the server. it should only be used if you were forced to change your history somehow (removing files with a password in it, rewinding work in an emergency), it should almost never be used and there should be a really good reason for it. i've used it maybe a dozen times last year of the thousands of pushes i've done.
Wait, what? I thought you were supposed to avoid "push --force" when pushing to a public repo?
My manpages still seem to warn against using both commands, but I'm locally running on a version dated 2/09/2009 (I have a cronjob at work that pulls down the latest version of git and compiles it daily).
[edit] Maybe by 'do the right thing' he means that it won't overwrite their local history (i.e. the pull/merge will fail because the histories are different)
Whenever you're rebasing, you should make sure you understand how git works and what the consequences are.
personally, i use a combination - i tend to rebase when it's only a couple of commits and i merge when there are dozens of commits off, whichever is easier/cleaner. if there are likely going to be conflicts to resolve, rebase is often a bit more difficult, and people tend to have a harder time understanding rebase conceptually so i tend not to encourage it's use to beginners. however, it's interesting to see how each person subtly differently sees how the world of VCS should be, and how Git makes it relatively easy to have such different workflows.
Anyway, "git push --force" has the potential to lose data, but less potential than "rm -rf .". You will destroy your central repository, not anyone's actual work. ("Destroy your central repository" sounds bad, but isn't. The important copy is the one on your disk.)
A clean history is better than never using "push -f" IMHO. The manual authors apparently disagree.
Pushing doesn't always mean to a central repository. Since there is no distinction, you could be git pushing while on a branch that is tracking a topic branch in someone else's local (local to them) repo.