11–17 of 17 posts
Git tries pretty hard to avoid this now; it won't treat fast-forwards as merge commits, it will just fast-forward you. Apparently this was not always the case. 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.)
I've read a number of times that you should never rebase commits that other people may have fetched already. Is this a possible danger here, or will git only rebase your strictly-local commits?
It will only rebase your local commits.
Whenever you're rebasing, you should make sure you understand how git works and what the consequences are.
Git tries pretty hard to avoid this now; it won't treat fast-forwards as merge commits, it will just fast-forward you. Apparently this was not always the case. 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.
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.
Git tries pretty hard to avoid this now; it won't treat fast-forwards as merge commits, it will just fast-forward you. Apparently this was not always the case. 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.)
please don't "git push --force" unless you know what it's doing, people - you will lose work and people will get really confused. the --force should never be necessary, even when using 'pull --rebase'. the push command normally will refuse to push unless the latest commit on the server is in your history somewhere. this means that if someone pushes since you last pushed or fetched, introducing commits you have not se…
Earlier quoted context omitted.
please don't "git push --force" unless you know what it's doing, people - you will lose work and people will get really confused. the --force should never be necessary, even when using 'pull --rebase'. the push command normally will refuse to push unless the latest commit on the server is in your history somewhere. this means that if someone pushes since you last pushed or fetched, introducing commits you have not se…
I liberally rewrite my history; this is why I push --force. I don't view version control as an auditing tool, I view it as a debugging tool. YMMV.