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

User · Answer

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.

User · Answer

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

User · Answer

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

User · Answer

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

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

Examples related to git