Pull vs. Fetch and merge in Git

You can update the remote repository's code locally using git fetch and git pull, but there is a difference between them. Today search git pull and fetch, found that the amount of information is very large, involved in git a lot of concepts, to my IQ estimates to fully understand very difficult, so first of all, the following content is I integrated the information on the Internet, my own understanding, if misleading, please understand.

First of all, I searched git pull and git fetch the difference, many online posts, I mainly refer to the http://www.tech126.com/git-fetch-pull/this post, I excerpt the main content.

git fetch

123	git fetch origin mastergit log -p master..origin/mastergit merge origin/master

1. Update the latest version to the Origin/master branch from the Master Master branch of the remote Origin repository
2. Compare the differences between the local master branch and the Origin/master branch
3. Merge content to local master branch

Another way to use Fetch is to refer to my previous article git to update the remote repository code locally.

Git pull

1	git pull origin master

The equivalent of git fetch and git merge, which is to update the remote repository's code to the local repository and then merge the content into the current branch.

So, simply say git pull is equivalent to git fetch and then a git merge. So what's the difference between the two of them, which requires that we get to know git again, and take a look at the following diagram:

We know that git actually has several zones, a workspace (workspace), staging Area (index), a local repository, and, of course, a remote repository (remotely repository). The remote repository keeps a copy of the code for us, such as GitHub, and the workspaces, staging area and local repositories are local, which is why we also use git commit code updates without the network, because commits are submitted to the local repository only. You can then push (push) to the remote repository after you have a network.

As shown, git fetch is to get updates to the remote repository to the local repository without affecting the other zones. Git pull, in turn, updates the remote repository's code to the workspace (and also updates the local repository).

In general, the difference between git fetch and merge and Git pull is obvious, but if you want to learn more about how git is going to work, then we need to understand the powerful features of this git (branching concept is really awesome, I'm not sure if my understanding is correct).

Branch

Branching (branches) is used to mark specific code submissions, each of which is identified by a sha1sum value, so the operations on the branch are lightweight-you change only the Sha1sum value. So why git advocates a lot of use of branching, because it's lightweight and flexible. To put it simply, there are two types of branching:

Native Branch (local branches), which is displayed when you enter "Git branch":

12	$ git branch  * master

Remote Branch (branches) ", when you enter" Git Branch-r "is displayed:

12	$ git branch -r  origin/master

If you are interested in how the branch is stored locally, look at the following file in the project, where the file contains a Sha1sum value:

• . git/refs/head/[Local Branch]
• . git/refs/remotes/[the branch being traced]

Let's take a look at the remote branch, Pro git This book describes very well. Remote Branch (branch) is the index of a branch in a remote repository. They are local branches that cannot be moved, and are only updated when Git is interacting with the network. The remote branch is like a bookmark that reminds you of the location of the previous branch when you connected to the remote repository.

We represent remote branches in the form of (remote warehouse name)/(branch name). For example, if we want to see what the master branch looks like when communicating with the Origin warehouse, we should look at the Origin/master branch. If you fix a problem with your partner, but they first push a iss53 branch to the remote repository, although you may also have a local ISS53 branch, the most recent update to the server should be the ORIGIN/ISS53 branch.

Here's a sample excerpt from the Pro git example. Suppose your team has a GIT server with an address of git.ourcompany.com. If you clone from here, Git will automatically name this remote repository as origin, download all of the data, create a pointer to its master branch, locally named Origin/master, but you can't change its data locally. Then, Git builds a local master branch of your own, starting with the same location as the Master branch on origin, and you can start working on this:

In this way, we have both local and remote branches in the local repository and start at the same location.

If you make some changes to the local master branch (the local workspace commits the code to the local repository), while others push their updates to git.ourcompany.com, the master branch on the server pushes forward, and at the same time, Your local submission history is moving in a different direction. However, as long as you do not communicate with the server, your origin/master pointer remains in place and does not move:

Note that the local branch has moved forward, and the remote branch remains motionless, and the remote repository master has actually moved forward, so it can be said that the local remote branch origin/master is obsolete.

You can run GIT fetch origin to synchronize the data on the remote server to local. The command first finds out which server origin is (in this case, git.ourcompany.com), gets the data you don't have, updates your local database (warehouse), and then moves the Origin/master pointer to its newest location:

Can you see the role of Git fetch now?

It's not over yet, so let's take a look at Git's advanced play method. To demonstrate how a project with multiple remote branches (on different remote servers) works, let's say you have another internal server git.team1.ourcompany.com that is only available to your Agile development team. It can be added as one of the remote branches of the current project using the GIT remote add command mentioned in Chapter two. We name it teamone to replace the full Git URL for ease of use:

Note Here are multiple remote branches, different remote servers.

Now you can use git fetch teamone to get the data you don't have on the team server. Since the current content on the server is a subset of your origin server, Git does not download any data, but simply creates a remote branch named Teamone/master, pointing to the Commit object 31b8e on the Teamone server where the master branch resides:

Thus you have two remote branches locally, as an index to the master branch on the two remote servers.

OK, not far, summarize git fetch and git pull:

• git fetch is the command, says "bring my local copy of the remote repository up to date."
• Git pull says "bring the changes in the remote repository where I keep my own code."

Because git pull hides the details of the process, you don't have to understand the different types of branches in git and how to use them. Of course, most of the time this is fine, but once the code has a problem, it's hard to find the wrong place. It looks like the use of Git pull will surprise you, and simply look at Git's usage documentation to convince you.
Another drawback to putting the download (fetch) and merge (merge) into one command is that your local working directory will be updated by the remote branch without confirmation.

It's a good idea to download and merge separately, and you can start by looking at the difference (diff) before deciding whether to merge with local code. and separate to do, you can clearly distinguish between the local branch and remote branch, convenient choice to use. So try to use git pull less, git fetch and merge more.

Reference:

http://www.oschina.net/translate/git-fetch-and-merge?cmp

Http://stackoverflow.com/questions/292357/difference-between-git-pull-and-git-fetch

Http://git-scm.com/book/zh/Git-%E5%88%86%E6%94%AF-%E8%BF%9C%E7%A8%8B%E5%88%86%E6%94%AF

Pull vs. Fetch and merge in Git