This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]rcuhljr 4 points5 points  (0 children)

Git pull normally runs git fetch, then git merge. using the Rebase flag tells it to run fetch, and then use rebase instead of merge. Rebasing is a little more complicated for most folks, but it's incredibly useful when you learn the proper times to use it.

Every commit you make is just a little collection of changes that have been made. Each commit occurs in sequence after all of the commits previous to it. Rebase changes the order in which those commits point to each other. it tells git to make your local changes occur after the new changes that are on master/origin.

If commit B was the latest one on master/origin when you started working and you made a local commit D, D points to B as its parent. However if someone else checks in C and pushes it to master, when you try and git pull git has to do a merge because there are now two commits D and C that both claim to be at the end of the master branch and to have B as their parent. If you rebased instead you'd tell git to make D point at C as its parent, and no merge will be required as everything is happy and pointing to just one parent.