What’s the difference between git pull and git pull --rebase

Question

In git I have the possibility to make a git pull origin master and a git pull --rebase origin master. I’d like to know the difference between the two.

Answer 1

To understand the differences, nothing better than a simple example.

Imagine you’re doing commits on the master branch with other people on your team. To simplify the scenario, you’re using Github to sync all commits on the master branch, using it as the main repository.

So let’s say there are the following commits at the moment master github.

M1<---M2<---M3

After you clone the repository, you make 2 more local commits (C1 and C2). On your machine, the repository will look like the following:

                  .---C1<---C2
                 /
M1<---M2<---M3<-´

However, at Gibhub, other developers have already done the push 3 more commits in master while you still have your 2 commits that are only in your local repository. In branch master of Github, we will then have the following situation:

M1<---M2<---M3<---M4<---M5<---M6

With the git pull, Git will generate a new commit that focuses the changes that have occurred as a result of this merge of the C1 and C2 commits with the M4, M5 and M6 commits. The command git pull does, behind the scenes, two things: a git fetch and a git merge.

At the stage of git fetch, you will receive the changes and have in your repository the following situation:

                  .---C1<---C2
                 /
M1<---M2<---M3<-´---M4<---M5<---M6

At the stage of merge, your repository will generate commit M7 as a result of this merge:

                  .----C1<---C2<----.
                 /                   \
M1<---M2<---M3<-´---M4<---M5<---M6<---`M7

But in different scenarios, Git doesn’t always generate this merge commit. Often only you’ve changed the master branch, including new commits. So by doing git pull, git does an operation fast forward, simply saying that your last commit is the end of the branch master:

                  .----C1<---C2
                 /            |       
M1<---M2<---M3<-´             |
                           [master]

The git rebase is a kind of merge also, but uses a different logic. Instead of generating a new commit, it reapplies each of the local branch commits "at the top" (at the top) of the remote branch’s last commit.

That is, if we have 2 commits (C1 and C2), they will be applied from the M7 commit.

Thus, when performing the rebase, we have the situation:

                                            .----C1’<---C2’
                                           /
M1<---M2<---M3<_--M4<---M5<---M6<---M7<-´

Note that I called C1 and C2 now C1 and C2. Why? After rebasing, these commits are not the same as the original commits. It will be totally new commits, even with different SHA (unique identifier and hash).

Answer 2

According to the official documentation, IF local branch is configured to track (track) changes to the remote branch And the remote branch has received some rebase since the last fetch that you have performed in your local repository, THEN --rebase command pull use this information to avoid re-applying non-local changes.

More pragmatically and in other words: git pull-rebase is to be used when updating (pull) a local branch with a remote branch that, before being sent to the network (push), suffered blending by rebase.

How not to wear rebase in branches used by more than one developer, both git rebase how much git pull-rebase should only be used in "Feature/topic branches".

The use of git pull-rebase is strongly associated with the need for a developer, who uses more than one computer in his day-to-day life, to keep up to date the local situation of a branch where he works on different machines (example: when the developer switches between remote and face-to-face work).