What is the difference between git pull --rebase and git pull origin. As per my understanding, basically git pull --rebase will update my local repo and update the branches whereas git pull origin will also update the local repo, so what is the difference between both commands?
-
1title should read git pull origin. But git pull updates your local repo with changes from the remote (origin). With rebase, your changes are added on top of changes pulled from the remote. In doing so, hopefully maintains a clean tree. – kirikoumath Dec 28 '18 at 21:26
2 Answers
Short answer:
Git pull origin performs a fetch and merges the fetched data with a merge
command.
git pull --rebase performs a fetch and merges the fetched data with a rebase
command.
Longer explaining answer: Lets say you have the following local history with some commits and two branches "master" and "experiment"
There are two ways to move changes from experiment to the master branch. The first method is the merge
command. It performs a three-way merge between the two latest branch snapshots (C3
and C4
) and the most recent common ancestor of the two (C2
), creating a new snapshot (and commit).
Method number two: you can take the patch of the change that was introduced in C4 and reapply it on top of C3. This is called rebasing. With the rebase command, you can take all the changes that were committed on one branch and replay them on another one.
In this example, you’d run the following:
$ git checkout experiment
$ git rebase master
It works by going to the common ancestor of the two branches (the one you’re on and the one you’re rebasing onto), getting the diff introduced by each commit of the branch you’re on, saving those diffs to temporary files, resetting the current branch to the same commit as the branch you are rebasing onto, and finally applying each change in turn.
At this point, you can go back to the master branch and do a fast-forward merge.
$ git checkout master
$ git merge experiment
There is no difference in the end product of the integration, but rebasing makes for a cleaner history. If you examine the log of a rebased branch, it looks like a linear history: it appears that all the work happened in series, even when it originally happened in parallel.
Note: Do not rebase commits that exist outside your repository.
If you follow that guideline, you’ll be fine. If you don’t, people will hate you, and you’ll be scorned by friends and family. Things will easily get messy in collaborating environments if this guideline is not followed.
Hope this helps :)

- 379
- 2
- 7
See the official docs for an authoritative reference.
For your specific question:
origin
here is the name of the remote repository you're pulling from, e.g. https://github.com/atom/atom.git
. If this value is ommitted, it uses the information from the current branch (which is usually origin
, since many developers only use one remote). The following are all valid commands:
git pull
git pull --rebase
git pull origin
git pull --rebase origin
The only difference is that the last two specify which remote repository they want to read their data from.
Thus, the comparison here is mainly between git pull
and git pull --rebase
, which hatati's answer or the official docs explain well. The docs for --rebase
:
When true, rebase the current branch on top of the upstream branch after fetching. If there is a remote-tracking branch corresponding to the upstream branch and the upstream branch was rebased since last fetched, the rebase uses that information to avoid rebasing non-local changes.

- 469
- 5
- 8