Difference between git merge and git fetch?
This question already has an answer here:
UPDATE - Good grief, my merge diagrams have been wrong this whole time. A merge doesn't move the "other" branch's ref...
git fetch is about retrieving data from a remote repository.
git merge is about combining work from multiple lines of work (usually local branches, but see below).
git pull (I know you didn't ask about pull but bear with me) is a shorthand that retrieves data from the remote like fetch , then merge s into your current branch the corresponding line of work from the remote (if there is one; the "tracking information" determines this.)
So for example, say you have a remote repo with a single branch ( master ) containing 5 commits.
'origin' repo
A --- B --- C --- D --- E <--(master)
A while ago you had cloned this repo; at the time only the first commit ( A ) was in it. You then created a new branch ( branch1 ) and did a little work, creating a new commit ( L ) on that branch. Lastly, you had pulled in changes from the remote; more on how that works later, but for now let's just say that you updated your master to include B .
local repo
A --- B <--(master)(origin/master)
L <-- (branch1)
Note that in addition to your local branch refs ( master and branch1 ) you have a remote branch reference ( origin/master ) which, for now, happens to be the same as master .
Now if you want to update your local repo to contain all the data from the origin, but without merging anything, you would say
git fetch
and then you have
C --- D --- E <--(origin/master)
/
A --- B <--(master)
L <-- (branch1)
That's a fetch - just get the data from the remote.
The main reason you'd explicitly ask for a merge would be to combine your work from branch1 with your master . So
git checkout master
git merge branch1
(then possibly resolve any conflicts) and you now have
C --- D --- E <--(origin/master)
/
A --- B --- M <--(master)
/
L ------- <--(branch1)
(Under some circumstances - where only one of the branches contains changes that aren't in the other - a merge can be done via "fast forward"; but that doesn't apply here since each branch had changes - ie the branches had diverged. Also there's another technique called rebasing that can sometimes be used to combine branches; but that's another can of worms...)
So that's the difference between fetch and merge - very different operations that do different things. But I also mentioned pull which kind of combines the two. If you do a pull , first it pulls changes from the remote (in case you haven't fully updated with fetch ), and then if the current branch has a corresponding remote branch, it merges them.
# still on master
git pull
gives something like
C --- D --- E --- N <--(master)(origin/master)
/ /
A --- B --------------- M
/
L ------------------- <--(branch1)
(Note that while I normally draw these diagrams such that the "straight line" coming into a merge is the "first parent", in this case that was getting to be troublesome for N ; but this does show the general commit topology...)
Back when I talked about "pulling in changes" to get B into your local repo, it likely would've been done using git pull
git fetch会下载源码树来检查更改，而git merge会将你当前的分支与另一个分支联系起来。
上一篇: git pull vs git有些混乱