Git's commit log is a hash tree (like the bitcoin block chain). When you commit you get a SHA for that commit. Part of the SHA contains the SHA of the commit before it. When you rebase it changes the SHA's of all the commits you've made. That's a lot of why you end up with conflicts when you don't know what you're doing. Never rebase if you've pushed the commits to a central repo because git will detect conflicts of the changes. You end up with duplicate commits with different SHAs after you resolve the conflicts and continue.
After reading this thread how many people would you guess have done that? Fairly good advice but if you wait for everyone to finish the book you'll wait forever. Better educate constructively when needed.
What you've said here is at best disingenuous, at worst outright wrong and confusing.
The changing of the SHA per se has nothing to do with why a conflict might arise. The conflict may arise because a particular commit could not cleanly be applied to the new base. The contents of the commit need not even change, which you can verify by looking at the actual contents of the commit, meaning the blobs that it contains. The blobs may stay the same (and indeed, will unless there's a conflict during the rebase), while the SHA changes.
> Part of the SHA contains the SHA of the commit before it.
This is incorrect.
A commit SHA has a tree SHA and a parent SHA associated with it. It's the parent SHA (the base of the commit) that changes when you rebase, which is a cascading change that continues down the tree in order as commits are applied. The SHA only changes because the SHA is a hash of the contents of the changeset and the time at which the commit was created.
You can see the commits along with their parent and tree hashes by doing `git log --format=raw`.
> Never rebase if you've pushed the commits to a central repo because git will detect conflicts of the changes.
This is also incorrect (or at least badly worded and disingenuous).
Git only knows that the changes you're attempting to push will cause you to lose data, which it says explicitly when you rebase a commit that's been pushed to the remote.
You should of course avoid rebasing commits that are on the remote unless you are the sole committer on the remote branch (meaning nobody else is pulling from that branch). You have to force push the branch when you do so, which is fine when you're the only person looking at it and disastrous when not.
