In git how is fetch different than pull and how is merge different than rebase?

Question

I just cant understand this. I been reading a lot on the web and books and something is just not staying in my head. Can someone please give me the dummy version of the following:

git fetch vs pull
git merge vs rebase

I sympathise with the questioner. The documentation and advice is so heavy and possible workflow permutations so massive that one gets extremely confused. Ones head just exploded and one doesn't know quite what to ask, it just isn't that obvious. — Ed Randall, Mar 05 '15 at 11:51

score 438 · Answer 1 · edited Nov 12 '15 at 17:40

438

fetch vs pull

fetch will download any changes from the remote* branch, updating your repository data, but leaving your local* branch unchanged.

pull will perform a fetch and additionally merge the changes into your local branch.

What's the difference? pull updates you local branch with changes from the pulled branch. A fetch does not advance your local branch.

merge vs rebase

Given the following history:

          C---D---E local
         /
    A---B---F---G remote

merge joins two development histories together. It does this by replaying the changes that occurred on your local branch after it diverged on top of the remote branch, and record the result in a new commit. This operation preserves the ancestry of each commit.

The effect of a merge will be:

          C---D---E local
         /         \
    A---B---F---G---H remote

rebase will take commits that exist in your local branch and re-apply them on top of the remote branch. This operation re-writes the ancestors of your local commits.

The effect of a rebase will be:

                  C'--D'--E' local
                 /
    A---B---F---G remote

What's the difference? A merge does not change the ancestry of commits. A rebase rewrites the ancestry of your local commits.

* This explanation assumes that the current branch is a local branch, and that the branch specified as the argument to fetch, pull, merge, or rebase is a remote branch. This is the usual case. pull, for example, will download any changes from the specified branch, update your repository and merge the changes into the current branch.

edited Nov 12 '15 at 17:40

LarsH

27,481
8
94
152

answered Feb 15 '13 at 13:14

pestrella

9,786
4
39
44

33

This by far is the simplest and best explanation without going into the debate behind each practice. Thank you! – Jonathan S. Fisher Mar 05 '14 at 02:59
3

Absolutely golden answer – ChaseMoskal May 17 '14 at 05:21
@techsjs2013, five pestrella his points :) Very concise and to the point answer. – diegovilar May 13 '15 at 11:42
5

Wish I could "favorite" this answer. Maybe I'll just print it and tape it on my wall. – LarsH Nov 12 '15 at 16:40
2

I would say the best of best answers I've got in stackoverflow, Thank you – Shahab J Jan 10 '17 at 22:06
1

If fetch only downloads changes from the remote branch and updates the repository data, but leaves the local branch unchanged, then what is the point of fetching if the working directory does not show/reflect the changes? My question originally was that how could I see the changes someone else has done and then decide whether I would like to merge them into my working directory (i.e. experiment with other people's changes to make sure it does not break my work) but I am still confused how to do that? Should I just pul and experiment/explore, and if it was problematic, do a hard reset? – Jun 09 '18 at 17:00
1

Hi @Joshua, it's often useful to know when there are new commits on the remote branch without disrupting work on your local branch. If you want to experiment with changes on the remote branch there are many ways to achieve this. Your suggestion is fine. Another way would be to detach `HEAD`, or simply to just create a new branch off the latest commit. It all depends on your specific situation. It's a greater topic of discussion and perhaps out of scope. – pestrella Jun 20 '18 at 12:31
1

This is similar but more detailed explanation here: https://www.derekgourlay.com/blog/git-when-to-merge-vs-when-to-rebase/ – tozka Oct 07 '18 at 17:36

score 29 · Answer 2 · edited May 23 '17 at 11:54

29

Fetch vs Pull

Git fetch just updates your repo data, but a git pull will basically perform a fetch and then merge the branch pulled

What is the difference between 'git pull' and 'git fetch'?

Merge vs Rebase

from Atlassian SourceTree Blog, Merge or Rebase:

Merging brings two lines of development together while preserving the ancestry of each commit history.

In contrast, rebasing unifies the lines of development by re-writing changes from the source branch so that they appear as children of the destination branch – effectively pretending that those commits were written on top of the destination branch all along.

Also, check out Learn Git Branching, which is a nice game that has just been posted to HackerNews (link to post) and teaches a lot of branching and merging tricks. I believe it will be very helpful in this matter.

edited May 23 '17 at 11:54

Community

1
1

answered Feb 15 '13 at 12:38

Felipe Sabino

17,825
6
78
112

thanks Felips.. so if I do a fetch from a remote my master branch will not have the updates? also it sounds like I should do rebase more then merga – techsjs2013 Feb 15 '13 at 13:02
rebase vs merge depends on what is your intention, having in mind that rebase rewrites all commits history. And yes, if you fetch only, the master branch won't be changed, you will have to merge (or pull) for it to apply the remote changes – Felipe Sabino Feb 15 '13 at 13:05
`git merge /`. for example, if your are the master branch and your remote is named origin, you can do `git merge origin/master`. – Felipe Sabino Feb 15 '13 at 13:43
so it sounds like I should always do a git checkout master git fetch git diff origin/master git rebase origin master – techsjs2013 Feb 15 '13 at 13:59

score 11 · Answer 3 · answered Feb 15 '13 at 13:17

pull vs fetch:

The way I understand this, is that git pull is simply a git fetch followed by git merge. I.e. you fetch the changes from a remote branch and then merge it into the current branch.

merge vs rebase:

A merge will do as the command says; merge the differences between current branch and the specified branch (into the current branch). I.e. the command git merge another_branch will the merge another_branch into the current branch.

A rebase works a bit differently and is kind of cool. Let's say you perform the command git rebase another_branch. Git will first find the latest common version between the current branch and another_branch. I.e. the point before the branches diverged. Then git will move this divergent point to the head of the another_branch. Finally, all the commits in the current branch since the original divergent point are replayed from the new divergent point. This creates a very clean history, with fewer branches and merges.

However, it is not without pitfalls! Since the version history is "rewritten", you should only do this if the commits only exists in your local git repo. That is: Never do this if you have pushed the commits to a remote repo.

The explanation on rebasing given in this online book is quite good, with easy-to-understand illustrations.

pull with rebasing instead of merge

I'm actually using rebase quite a lot, but usually it is in combination with pull:

git pull --rebase

will fetch remote changes and then rebase instead of merge. I.e. it will replay all your local commits from the last time you performed a pull. I find this much cleaner than doing a normal pull with merging, which will create an extra commit with the merges.

so if I am working in and branch and I want to merge it back into the master before I do a push. I should checkout master, then do get rebase fix? — techsjs2013, Feb 15 '13 at 14:33
I think the illustrations provided by the answer from pestrella shows the difference quite clearly. Also, check out: http://git-scm.com/book/en/Git-Branching-Rebasing - which does a pretty decent job of explaining it (same link as the one in the answer, but given again for the lazy ones). — Steinar, Feb 18 '13 at 14:56

score 0 · Answer 4 · answered May 31 '18 at 09:31

Merge - HEAD branch will generate a new commit, preserving the ancestry of each commit history. History can become polluted if merge commits are made by multiple people who work on the same branch in parallel.

Rebase - Re-writes the changes of one branch onto another without creating a new commit. The code history is simplified, linear and readable but it doesn't work with pull requests, because you can't see what minor changes someone made.

I would use git merge when dealing with feature-based workflow or if I am not familiar with rebase. But, if I want a more a clean, linear history then git rebase is more appropriate. For more details be sure to check out this merge or rebase article.

In git how is fetch different than pull and how is merge different than rebase?

4 Answers4

fetch vs pull

merge vs rebase

Linked