Git pull 和 git fetch 之间有什么区别？

git pull 和 git fetch 都是 Git 版本控制系统中用于从远程仓库获取最新更改的命令，但它们的行为有一些关键区别。

git fetch

git fetch 命令用于从远程仓库下载本地仓库中不存在的所有信息。这包括获取所有远程分支的更新，但并不自动合并到当前工作分支中。git fetch 只是下载远程的最新数据到本地仓库，但不会改变用户的工作状态（即用户当前的工作目录内容和当前分支不会受到影响）。这允许用户在合并之前手动查看这些更改。

例如，如果你想要查看远程主分支的更改，但还不准备合并它们到你的本地主分支，你可以执行：

shell
git fetch origin master

之后，你可以使用 git diff 命令来比较本地分支和远程分支的差异。

git pull

git pull 实际上是 git fetch 紧接着一个 git merge 命令的组合。当运行 git pull 时，Git 会从远程仓库获取当前分支的最新更改，并尝试自动合并到本地的相应分支中。这意味着，如果你在主分支上执行 git pull，Git 会自动下载远程主分支的更新，并将它们合并到你的本地主分支。

例如，要更新你的本地主分支，你可以执行：

shell
git pull origin master

这会获取远程主分支的更新并尝试将它们合并到你的本地主分支。

总结

• git fetch 是一种更为安全和细致的更新方式，因为它允许用户在不影响当前工作的情况下查看远程更改。
• git pull 是一种更为便捷的方式，因为它会自动下载并合并更改，但如果有合并冲突，需要用户手动解决。

在实际工作中，你可能会用 git fetch 来确保对远程仓库的更改有充分的了解和审查，然后再决定是否使用 git merge 来合并这些更改，或者用 git rebase 来整理本地提交历史。而 git pull 则适用于当你信任远程更改，并且想要快速更新你的本地分支时使用。

In the simplest terms, git pull does a git fetch followed by a git merge.

git fetch updates your remote-tracking branches under refs/remotes/<remote>/. This operation is safe to run at any time since it never changes any of your local branches under refs/heads.

git pull brings a local branch up-to-date with its remote version, while also updating your other remote-tracking branches.

From the Git documentation for git pull:

git pull runs git fetch with the given parameters and then depending on configuration options or command line flags, will call either git rebase or git merge to reconcile diverging branches.

• git pull tries to automatically merge after fetching commits. It is context sensitive, so all pulled commits will be merged into your currently active branch. git pull automatically merges the commits without letting you review them first. If you don’t carefully manage your branches, you may run into frequent conflicts.

• git fetch gathers any commits from the target branch that do not exist in the current branch and stores them in your local repository. However, it does not merge them with your current branch. This is particularly useful if you need to keep your repository up to date, but are working on something that might break if you update your files. To integrate the commits into your current branch, you must use git merge afterwards.

It is important to contrast the design philosophy of git with the philosophy of a more traditional source control tool like SVN.

Subversion was designed and built with a client/server model. There is a single repository that is the server, and several clients can fetch code from the server, work on it, then commit it back to the server. The assumption is that the client can always contact the server when it needs to perform an operation.

Git was designed to support a more distributed model with no need for a central repository (though you can certainly use one if you like). Also git was designed so that the client and the "server" don't need to be online at the same time. Git was designed so that people on an unreliable link could exchange code via email, even. It is possible to work completely disconnected and burn a CD to exchange code via git.

In order to support this model git maintains a local repository with your code and also an additional local repository that mirrors the state of the remote repository. By keeping a copy of the remote repository locally, git can figure out the changes needed even when the remote repository is not reachable. Later when you need to send the changes to someone else, git can transfer them as a set of changes from a point in time known to the remote repository.

• git fetch is the command that says "bring my local copy of the remote repository up to date."

• git pull says "bring the changes in the remote repository to where I keep my own code."

Normally git pull does this by doing a git fetch to bring the local copy of the remote repository up to date, and then merging the changes into your own code repository and possibly your working copy.

The take away is to keep in mind that there are often at least three copies of a project on your workstation. One copy is your own repository with your own commit history. The second copy is your working copy where you are editing and building. The third copy is your local "cached" copy of a remote repository.

Here is Oliver Steele's image of how all it all fits together:

One use case of git fetch is that the following will tell you any changes in the remote branch since your last pull... so you can check before doing an actual pull, which could change files in your current branch and working copy.

shell
git fetch
git diff ...origin

See git diff documentation regarding the double- .. and triple-dot ... syntax.