[英]What is the difference between 'git pull' and 'git fetch'?
git pull尝试在获取提交后自动合并。 它是上下文敏感的，因此所有拉取的提交都将合并到您当前活动的分支中。 git pull自动合并提交，而不让您先查看它们。 如果你不仔细管理你的分支，你可能会遇到频繁的冲突。
git fetch从目标分支收集当前分支中不存在的所有提交，并将它们存储在本地存储库中。 但是，它不会将它们与您当前的分支合并。 如果您需要使存储库保持最新状态，但正在处理可能会因更新文件而中断的事情，这将特别有用。 要将提交集成到您当前的分支中，您必须在之后使用git merge 。
将 git 的设计理念与更传统的源代码控制工具（如 SVN）的理念进行对比非常重要。
Subversion 是使用客户端/服务器模型设计和构建的。 有一个存储库是服务器，多个客户端可以从服务器获取代码，对其进行处理，然后将其提交回服务器。 假设客户端在需要执行操作时始终可以联系服务器。
Git 旨在支持更分布式的模型，而不需要中央存储库（尽管您当然可以根据需要使用一个）。 git 也被设计成客户端和“服务器”不需要同时在线。 Git 的设计目的是让不可靠链接上的人们甚至可以通过电子邮件交换代码。 可以完全断开连接并刻录 CD 以通过 git 交换代码。
为了支持这个模型，git 使用你的代码维护一个本地存储库，以及一个反映远程存储库状态的附加本地存储库。 通过在本地保存远程存储库的副本，即使远程存储库无法访问，git 也可以找出所需的更改。 稍后当您需要将更改发送给其他人时，git 可以将它们作为一组更改从已知的时间点传输到远程存储库。
git fetch是说“使我的远程存储库的本地副本保持最新”的命令。
git pull说“将远程存储库中的更改带到我保存自己代码的地方。”
通常git pull通过执行git fetch来更新远程存储库的本地副本，然后将更改合并到您自己的代码存储库和可能的工作副本中。
需要记住的是，您的工作站上通常至少有三个项目副本。 一个副本是您自己的存储库，其中包含您自己的提交历史记录。 第二个副本是您正在编辑和构建的工作副本。 第三个副本是远程存储库的本地“缓存”副本。
git fetch的一个用例是，以下内容将告诉您自上次拉取以来远程分支中的任何更改......因此您可以在进行实际拉取之前进行检查，这可能会更改当前分支和工作副本中的文件。
git fetch
git diff ...origin
请参阅有关双..和三点...语法的git diff文档。
我花了一点时间来理解有什么区别，但这是一个简单的解释。 本地master是一个分支。
克隆存储库时，您会将整个存储库获取到本地主机。 这意味着那时您有一个指向HEAD的 origin/master 指针和指向同一个HEAD的 master 。
当您开始工作并提交时，您将主指针前进到HEAD + 您的提交。 但是原点/主指针仍然指向克隆时的位置。
所以区别将是：
git fetch ，它将仅获取远程存储库 ( GitHub ) 中的所有更改并将 origin/master 指针移动到HEAD 。 同时，您的本地分支主管将继续指向它所在的位置。git pull ，它将基本上执行 fetch （如前所述）并将任何新更改合并到您的 master 分支并将指针移动到HEAD 。有时，视觉表示会有所帮助。
更简短的
git fetch获取更新但不合并它们。
git pull在后台执行git fetch ，然后执行merge 。
简要地
git fetch类似于pull但不合并。 即它获取远程更新（ refs和objects ），但您的本地保持不变（即origin/master得到更新，但master保持不变）。
git pull从远程下拉并立即合并。
更多的
git clone克隆一个 repo。
git rebase将当前分支中不在上游分支中的内容保存到临时区域。 您的分支现在与开始更改之前相同。 因此， git pull -rebase将拉下远程更改，倒回您的本地分支，在当前分支的顶部一一重播您的更改，直到您保持最新状态。
此外， git branch -a将准确地向您展示所有分支（本地和远程）的情况。
这篇博文很有用：
git pull、git fetch 和 git clone（和 git rebase）之间的区别 - Mike Pearce
并涵盖git pull 、 git fetch 、 git clone和git rebase 。
我想我会更新这个来展示你在实践中是如何使用它的。
从远程更新您的本地仓库（但不要合并）：
git fetch下载更新后，让我们看看差异：
git diff master origin/master如果您对这些更新感到满意，请合并：
git pull笔记：
第 2 步：有关本地和远程之间差异的更多信息，请参阅： 如何将本地 Git 分支与其远程分支进行比较
在第 3 步：在这里做一个git rebase origin可能更准确（例如在一个快速变化的 repo 上）。 请参阅另一个答案中的@Justin Ohms 评论。
另见：http: //longair.net/blog/2009/04/16/git-fetch-and-merge/
另请注意：我在pull期间提到了merge ，但是您可以将pull配置为使用rebase 。
git-pull - Fetch from and merge with another repository or a local branch SYNOPSIS git pull … DESCRIPTION Runs git-fetch with the given parameters, and calls git-merge to merge the retrieved head(s) into the current branch. With --rebase, calls git-rebase instead of git-merge. Note that you can use . (current directory) as the <repository> to pull from the local repository — this is useful when merging local branches into the current branch. Also note that options meant for git-pull itself and underlying git-merge must be given before the options meant for git-fetch.
如果你想合并历史，你会拉，如果你只是“想要 codez”，你会提取，因为有人在这里标记了一些文章。
好的，这里有一些关于git pull和git fetch的信息，所以你可以了解实际的区别......简单来说， fetch获取最新数据，而不是代码更改并且不会弄乱你当前的本地分支代码，但是拉取代码更改并将其合并到您的本地分支，请继续阅读以获取有关每个更改的更多详细信息：
它将所有引用和对象以及任何新分支下载到您的本地存储库...
从一个或多个其他存储库中获取分支和/或标签（统称为“引用”），以及完成其历史所需的对象。 远程跟踪分支已更新（有关控制此行为的方法，请参见下面的描述）。
默认情况下，任何指向正在获取的历史的标签也会被获取； 效果是获取指向您感兴趣的分支的标签。可以通过使用 --tags 或 --no-tags 选项或配置 remote..tagOpt 来更改此默认行为。 通过使用显式获取标签的 refspec，您也可以获取不指向您感兴趣的分支的标签。
git fetch 可以从单个命名存储库或 URL 或从多个存储库中获取，如果给定并且有一个遥控器。 配置文件中的条目。 （见 git-config 1 ）。
如果未指定远程，默认情况下将使用原始远程，除非为当前分支配置了上游分支。
获取的 ref 的名称以及它们指向的对象名称被写入 .git/FETCH_HEAD。 脚本或其他 git 命令（例如 git-pull）可能会使用此信息。
它会将远程的更改应用到本地的当前分支...
将来自远程存储库的更改合并到当前分支中。 在其默认模式下，git pull 是 git fetch 后跟 git merge FETCH_HEAD 的简写。
更准确地说， git pull 使用给定的参数运行 git fetch 并调用 git merge 以将检索到的分支头合并到当前分支中。 使用 --rebase，它运行 git rebase 而不是 git merge。
应该是传递给 git-fetch 1的远程存储库的名称。 可以命名任意远程引用（例如，标签的名称），甚至是具有相应远程跟踪分支的引用集合（例如，refs/heads/ :refs/remotes/origin/ ），但通常是名称远程存储库中的一个分支。
和 的默认值是从 git-branch --track 设置的当前分支的“远程”和“合并”配置中读取的。
我还创建了下面的视觉效果，向您展示git fetch和git pull如何一起工作......
您可以从远程存储库中获取，查看差异，然后提取或合并。
这是一个名为origin的远程存储库和一个名为master的分支跟踪远程分支origin/master的示例：
git checkout master
git fetch
git diff origin/master
git rebase origin master
简短而简单的答案是git pull只是git fetch后跟git merge 。
需要注意的是，不管你喜不喜欢， git pull都会自动合并。 当然，这可能会导致合并冲突。 假设您的遥控器是origin而您的分支是master 。 如果您在拉取之前git diff origin/master ，您应该对潜在的合并冲突有所了解，并可以相应地准备您的本地分支。
除了拉取和推送之外， 一些工作流程还涉及git rebase ，例如这个，我从链接的文章中转述：
git pull origin master
git checkout foo-branch
git rebase master
git push origin foo-branch
如果你发现自己处于这种情况，你可能会想git pull --rebase 。 除非你真的，真的知道你在做什么，否则我建议不要这样做。 此警告来自git-pull的man页，版本2.3.5 ：
这是一种潜在的危险操作模式。 它改写了历史，当您已经发布了该历史时，这并不是一个好兆头。 除非您仔细阅读 git-rebase(1)，否则不要使用此选项。
这种交互式图形表示对于理解 git 非常有帮助：http: //ndpsoftware.com/git-cheatsheet.html
git fetch只是将更改从远程“下载”到本地存储库。 git pull下载更改并将它们合并到您当前的分支中。 “在其默认模式下， git pull是git fetch后跟git merge FETCH_HEAD的简写。”
在谈到上述答案中的 pull & fetch 时，我想分享一个有趣的技巧，
git pull --rebase上面这个命令是我 git 生活中最有用的命令，它节省了很多时间。
在将您的新提交推送到服务器之前，请尝试此命令，它会自动同步最新的服务器更改（使用 fetch + 合并）并将您的提交放在 git log 的顶部。 无需担心手动拉/合并。
在以下位置查找详细信息：http: //gitolite.com/git-pull--rebase
我喜欢对情况有一些直观的表示来掌握这些东西。 也许其他开发人员也想看到它，所以这是我的补充。 我不完全确定这一切都是正确的，所以如果您发现任何错误，请发表评论。
LOCAL SYSTEM
. =====================================================
================= . ================= =================== =============
REMOTE REPOSITORY . REMOTE REPOSITORY LOCAL REPOSITORY WORKING COPY
(ORIGIN) . (CACHED)
for example, . mirror of the
a github repo. . remote repo
Can also be .
multiple repo's .
.
.
FETCH *------------------>*
Your local cache of the remote is updated with the origin (or multiple
external sources, that is git's distributed nature)
.
PULL *-------------------------------------------------------->*
changes are merged directly into your local copy. when conflicts occur,
you are asked for decisions.
.
COMMIT . *<---------------*
When coming from, for example, subversion, you might think that a commit
will update the origin. In git, a commit is only done to your local repo.
.
PUSH *<---------------------------------------*
Synchronizes your changes back into the origin.
获取遥控器镜像的一些主要优点是：
GIT Fetch和GIT Pull之间的区别可以用以下场景来解释：（请记住，图片胜于雄辩！，我提供了图片表示）
让我们举一个例子，您正在与您的团队成员一起处理一个项目。 所以项目会有一个主分支，所有贡献者必须将它分叉到他们自己的本地存储库，然后在这个本地分支上修改/添加模块，然后推回主分支。
因此，当您在本地存储库上分叉主项目时，两个分支的初始状态将是这样的-（ A 、 B和C是项目已经完成的模块）
现在，您已经开始开发新模块（假设D ），当您完成D模块后，您想将其推送到主分支，但与此同时，您的一个队友开发了新的模块E 、 F和修改C .
所以现在发生的事情是您的本地存储库落后于项目的原始进度，因此将您的更改推送到主分支可能会导致冲突并可能导致您的模块D出现故障。
为避免此类问题并与项目的原始进度并行工作，有两种方法：
1. Git Fetch -这将下载对 origin/main 分支项目所做的所有更改，这些更改不存在于您的本地分支中。 并将等待 Git Merge 命令将已获取的更改应用到您的存储库或分支。
所以现在您可以在将文件合并到您的存储库之前仔细监控文件。 由于修改了C ，您还可以根据需要修改D 。
2. Git Pull-这将使用原始/主分支更新您的本地分支，即实际上它所做的是Git Fetch 和Git 一个接一个合并的组合。 但这可能会导致发生冲突，因此建议使用带有干净副本的 Git Pull。
我也为此苦苦挣扎。 事实上，我通过谷歌搜索完全相同的问题来到这里。 阅读所有这些答案最终在我的脑海中描绘了一幅画面，我决定尝试通过查看 2 个存储库和 1 个沙箱的状态以及在查看它们的版本时随时间执行的操作来了解这一点。 所以这就是我想出的。 如果我在任何地方搞砸了，请纠正我。
三个带有 fetch 的 repos：
--------------------- ----------------------- -----------------------
- Remote Repo - - Remote Repo - - Remote Repo -
- - - gets pushed - - -
- @ R01 - - @ R02 - - @ R02 -
--------------------- ----------------------- -----------------------
--------------------- ----------------------- -----------------------
- Local Repo - - Local Repo - - Local Repo -
- pull - - - - fetch -
- @ R01 - - @ R01 - - @ R02 -
--------------------- ----------------------- -----------------------
--------------------- ----------------------- -----------------------
- Local Sandbox - - Local Sandbox - - Local Sandbox -
- Checkout - - new work done - - -
- @ R01 - - @ R01+ - - @R01+ -
--------------------- ----------------------- -----------------------
拉动的三个回购
--------------------- ----------------------- -----------------------
- Remote Repo - - Remote Repo - - Remote Repo -
- - - gets pushed - - -
- @ R01 - - @ R02 - - @ R02 -
--------------------- ----------------------- -----------------------
--------------------- ----------------------- -----------------------
- Local Repo - - Local Repo - - Local Repo -
- pull - - - - pull -
- @ R01 - - @ R01 - - @ R02 -
--------------------- ----------------------- -----------------------
--------------------- ----------------------- -----------------------
- Local Sandbox - - Local Sandbox - - Local Sandbox -
- Checkout - - new work done - - merged with R02 -
- @ R01 - - @ R01+ - - @R02+ -
--------------------- ----------------------- -----------------------
这帮助我理解了为什么 fetch 非常重要。
我们简单地说：
git pull == git fetch + git merge
如果运行git pull ，则不需要将数据合并到本地。 如果您运行git fetch ，则意味着您必须运行git merge才能将最新代码获取到本地计算机。 否则，不合并就不会更改本地机器代码。
所以在 Git Gui 中，当你获取数据时，你必须合并数据。 Fetch 本身不会在您的本地进行代码更改。 您可以通过获取一次获取并查看来检查更新代码时； 它不会改变的代码。 然后合并...您将看到更改后的代码。
简单来说，如果您要在没有任何 Internet 连接的情况下跳上飞机……在出发之前，您可以执行git fetch origin <branch> 。 它会将所有更改提取到您的计算机中，但将其与您的本地开发/工作区分开。
在飞机上，您可以对本地工作区进行更改，然后将其与您之前获取的内容合并，然后解决潜在的合并冲突，所有这些都无需连接到 Internet。 除非有人对远程存储库进行了新的更改，否则一旦您到达目的地，您将执行git push origin <branch>并去喝咖啡。
从这个很棒的 Atlassian 教程中：
git fetch命令将提交、文件和引用从远程存储库下载到本地存储库。当您想查看其他人一直在做什么时，您会执行获取操作。 它类似于 SVN 更新，因为它可以让您查看中央历史记录的进展情况，但它不会强制您将更改实际合并到您的存储库中。 Git将获取的内容与现有的本地内容隔离开来，它对您的本地开发工作绝对没有影响。 必须使用
git checkout命令明确签出获取的内容。 这使得在将提交与本地存储库集成之前，获取一种安全的方式来审查提交。从远程存储库下载内容时，可以使用
git pull和git fetch命令来完成任务。 您可以考虑git fetch这两个命令的“安全”版本。 它将下载远程内容，但不会更新本地存储库的工作状态，从而使您当前的工作保持不变。git pull是更激进的选择，它将下载活动本地分支的远程内容并立即执行git merge为新的远程内容创建合并提交。 如果您有正在进行的未决更改，这将导致冲突并启动合并冲突解决流程。
使用git pull ：
git merge 。git fetch它只影响你的.git/refs/remotes ， git pull 会影响你的.git/refs/remotes和.git/refs/heads/ 嗯...所以如果我不使用git fetch更新工作副本，那么我在哪里进行更改？ Git fetch 在哪里存储新的提交？
好问题。 首先， heads或remotes不存储新的提交。 他们只是有提交的指针。 因此，使用git fetch您可以下载最新的git 对象（blob、tree、commits。要完全了解这些对象，请在 git internals 上观看此视频），但只需更新您的remotes指针以指向该分支的最新提交。 它仍然与您的工作副本隔离，因为您的分支在heads目录中的指针尚未更新。 它只会在merge / pull时更新。 但又在哪里？ 让我们来了解一下。
在您的项目目录中（即，您执行git命令的位置）执行以下操作：
ls 。 这将显示文件和目录。 没什么酷的，我知道。
现在做ls -a 。 这将显示点文件，即以 . 开头的文件. 然后，您将能够看到一个名为： .git的目录。
做cd .git 。 这显然会改变你的目录。
有趣的来了; 做ls 。 您将看到目录列表。 我们正在寻找refs 。 做cd refs 。
查看所有目录中的内容很有趣，但让我们关注其中的两个。 heads和remotes 。 也可以使用cd检查它们的内部。
您执行的任何git fetch操作都会更新/.git/refs/remotes目录中的指针。 它不会更新/.git/refs/heads目录中的任何内容。
任何git pull都会首先执行git fetch ，更新/.git/refs/remotes目录中的项目，然后与本地合并，然后更改/.git/refs/heads目录中的头。
一个非常好的相关答案也可以在“git fetch”放在哪里？ .
另外，从Git 分支命名约定帖子中查找“斜线表示法”。 它可以帮助你更好地理解 Git 如何将东西放在不同的目录中。
做就是了：
git fetch origin master
git checkout master
如果远程主机已更新，您将收到如下消息：
Your branch is behind 'origin/master' by 2 commits, and can be fast-forwarded.
(use "git pull" to update your local branch)
如果您没有fetch并且只是做了git checkout master那么您的本地 git 不会知道添加了 2 个提交。 它只会说：
Already on 'master'
Your branch is up to date with 'origin/master'.
但这是过时和不正确的。 这是因为 git 只会根据它所知道的信息给你反馈。 它忘记了它尚未撤消的新提交......
一些 IDE（例如 Xcode）非常智能，并且使用git fetch的结果，并且可以注释在当前工作分支的远程分支中已更改的代码行。 如果该行已被本地更改和远程分支更改，则该行将被标记为红色。 这不是合并冲突。 这是一个潜在的合并冲突。 这是一个提示，您可以在从远程分支执行git pull之前使用它来解决未来的合并冲突。
如果您获取远程分支，例如：
git fetch origin feature/123
然后这将进入您的远程目录。 您的本地目录仍然无法使用它。 但是，它通过 DWIM 简化了您对该远程分支的结帐（按我的意思做）：
git checkout feature/123
你不再需要做：
git checkout -b feature/123 origin/feature/123
有关更多信息，请在此处阅读
git fetch将代码从远程服务器下拉到本地存储库中的跟踪分支。 如果您的远程被命名为origin （默认），那么这些分支将位于origin/内，例如origin/master 、 origin/mybranch-123等。这些不是您当前的分支，它们是来自服务器的这些分支的本地副本.
git pull执行git fetch ，但随后还将跟踪分支中的代码合并到该分支的当前本地版本中。 如果您还没有准备好进行更改，请先git fetch 。
git fetch将检索远程分支，以便您可以git diff或git merge它们与当前分支合并。 git pull将在当前分支跟踪的远程分支上运行 fetch，然后合并结果。 您可以使用git fetch查看远程分支是否有任何更新，而无需将它们与本地分支合并。
Git 获取
您通过 fetch 将更改从 origin 下载到本地分支。 Fetch 向远程存储库询问其他人已提交但您在本地存储库中没有的所有提交。 Fetch 下载这些提交并将它们添加到本地存储库。
Git 合并
您可以使用 merge 命令应用通过 fetch 下载的更改。 Merge 将获取从 fetch 中检索到的提交，并尝试将它们添加到您的本地分支。 合并将保留您本地更改的提交历史，以便当您通过推送共享您的分支时，Git 将知道其他人如何合并您的更改。
Git 拉取
fetch 和 merge 经常一起运行，以至于创建了一个将两者结合在一起的命令 pull。 拉取然后合并以将下载的提交添加到您的本地分支。
git pull和git fetch之间的唯一区别是：
git pull从远程分支中拉取并合并它。
git fetch仅从远程分支获取，但不合并
即 git pull = git fetch + git merge ...
Git 允许在较新的提交之后应用按时间顺序较旧的提交。 因此，在存储库之间传输提交的行为分为两个步骤：
将远程分支的新提交复制到本地仓库中此远程分支的副本。
（repo 到 repo 操作） master@remote >> remote/origin/master@local
将新提交集成到本地分支
（内部仓库操作） remote/origin/master@local >> master@local
第 2 步有两种方法。您可以：
在git术语中，第 1 步是git fetch ，第 2 步是git merge或git rebase
git pull是git fetch和git merge
git pull命令实际上是git fetch后跟git merge或git rebase命令的shortcut ，具体取决于您的配置。 您可以配置您的 Git 存储库，以便git pull是 fetch 后跟 rebase。
Git 使用两条命令从远程获取最新版本的分支到本地：
git fetch：Git 会从远程获取最新版本到本地，但不会自动合并。 git fetch origin master git log -p master..origin/master git merge origin/master
上面的命令意味着将最新版本的主分支从远程从源下载到源主分支。 然后比较本地master分支和origin master分支。 最后，合并。
git pull：Git 将从远程获取最新版本并合并到本地。
git pull origin master
上面的命令相当于git fetch和git merge 。 在实践中， git fetch可能更安全，因为在合并之前我们可以看到更改并决定是否合并。
git pull和git fetch有什么区别？
要理解这一点，您首先需要了解您的本地 git 不仅维护您的本地存储库，而且还维护远程存储库的本地副本。
git fetch使您的远程存储库的本地副本保持最新。 例如，如果您的远程存储库是 GitHub - 您可能希望将远程存储库中所做的任何更改提取到远程存储库的本地副本。 这将允许您执行比较或合并等操作。
另一方面， git pull会将远程存储库中的更改带到您保存自己代码的位置。 通常， git pull将首先执行git fetch以使远程存储库的本地副本保持最新，然后它将更改合并到您自己的代码存储库和可能的工作副本中。
初学者的简单图形表示，
这里，
git pull
将从存储库中获取代码并使用您的本地重新设置...在 git pull 中，有可能创建新的提交。
但在 ，
获取
将从存储库中获取代码，我们需要使用git rebase手动对其进行变基
例如：我将从服务器主服务器获取并在我的本地主服务器中重新设置它。
1) git pull ( rebase 会自动完成):
git pull origin master
这里origin是你的远程仓库master是你的分支
2）git fetch（需要手动变基）：
git fetch origin master
它将从原点获取服务器更改。 它将在您的本地，直到您自己重新设置它。 我们需要通过检查代码手动修复冲突。
git rebase origin/master
这会将代码变基为本地代码。 在此之前确保您在正确的分支中。
git pull == ( git fetch + git 合并)
git fetch 不会更改本地分支。
如果您已经有一个为所需项目设置了远程的本地存储库，则可以使用 git fetch 获取现有远程的所有分支和标签。 ... Fetch 不会对本地分支进行任何更改，因此您需要将远程分支与配对的本地分支合并以合并新的 fetch 更改。 来自 github
实际上，Git 维护您自己的代码和远程存储库的副本。
命令git fetch通过从远程存储库获取数据使您的本地副本保持最新。 我们需要这个的原因是因为其他人可能对代码进行了一些更改，而您希望自己保持更新。
命令git pull将远程存储库中的更改带到您保存自己代码的位置。 通常， git pull通过首先执行“git fetch”来使远程存储库的本地副本保持最新，然后将更改合并到您自己的代码存储库和可能的工作副本中。
git pull = git fetch + git merge
git 拉
它使用一个命令执行两个功能。
它获取对远程分支所做的所有更改，然后将这些更改合并到您的本地分支中。 您还可以通过传递 --rebase 来修改 pull 的行为。 可以在这里阅读合并和变基之间的区别
获取
Git fetch 只完成了 git pull 的一半工作。 它只是将远程更改带入您的本地存储库，但不会将它们应用到您的分支。您必须明确应用这些更改。 这可以按如下方式完成：
git fetch
git rebase origin/master
必须牢记 git 的性质。 您有遥控器和本地分支机构（不一定相同）。 与其他源代码控制系统相比，这可能有点令人困惑。
通常，当您签出远程时，会创建一个跟踪远程的本地副本。
git fetch 将与远程分支一起使用并更新您的信息。
如果其他 SWE 正在同一个分支工作，实际上就是这种情况，而在小型开发 - 一个分支 - 一个项目场景中很少出现这种情况。
您在当地分支机构的工作仍然完好无损。 为了将更改带到您的本地分支，您必须合并/重新设置远程分支的更改。
git pull 正是这两个步骤（即 --rebase 到 rebase 而不是 merge ）
如果您的本地历史和远程历史有冲突，您将被迫在 git push 期间进行合并以发布您的更改。
因此，这实际上取决于您的工作环境的性质和使用什么的经验。
所有分支都存储在.git/refs
所有本地分支都存储在.git/refs/heads
所有远程分支都存储在.git/refs/remotes
git fetch命令将提交、文件和引用从远程存储库下载到本地存储库。 当您想查看其他人一直在做什么时，您会执行获取操作。
因此，当您执行git fetch时，所有文件、提交和引用都会下载到
这个目录.git/refs/remotes
您可以切换到这些分支以查看更改。
此外，您可以根据需要合并它们。
git pull只是下载这些更改并将它们合并到当前分支。
例子
如果你想看到远程分支dev/jd/feature/auth的工作，你只需要做
git fetch origin dev/jd/feature/auth
查看更改或工作进度，
git checkout dev/jd/feature/auth
但是，如果您还想在当前分支中获取并合并它们，
git pull origin dev/jd/feature/auth
如果您执行git fetch origin branch_name ，它将获取分支，现在您可以切换到您想要的分支并查看更改。 您的本地 master 或其他本地分支不会受到影响。 但是git pull origin branch_name将获取分支并合并到当前分支。
简单解释：
git fetch
获取元数据。 如果您想签出最近创建的分支，您可能需要在结帐前进行提取。
git pull
从远程获取元数据，并将文件从远程移动并合并到分支
Git 获取
帮助您了解来自git repository的最新更新。 假设您在使用GitFlow的团队中工作，团队在多个branches （功能）上工作。 使用git fetch --all command ，您可以了解repository中的所有新branches 。
大多数情况下git fetch与git reset一起使用。 例如，您希望将所有本地更改恢复到当前存储库状态。
git fetch --all // get known about latest updates
git reset --hard origin/[branch] // revert to current branch state
git拉
此命令使用当前repository branch状态更新您的branch 。 让我们继续GitFlow 。 多个功能branches merged到develop分支，当您想为项目开发新功能时，您必须转到开发branch并执行git pull以获取develop branch的当前状态
这张图可能会有所帮助。 git pull本质上等同于git fetch然后git merge
Git获取：
Git fetch 是一个允许您从另一个存储库下载对象的命令。
Git 拉取：
Git pull 是一个命令，它允许您从另一个存储库或本地分支获取并与之集成。
什么时候应该使用 Git Fetch？
如果您只想查看远程存储库中的所有当前分支和更改，Git fetch 可以获取您需要的所有信息，而无需实际对您的工作进行任何本地更改。
命令：
$ git 获取原点
什么时候应该使用 Git Pull？
当您对将从远程存储库获取并添加到本地副本的更改有完整的上下文时，Git pull 是一个理想的操作。
命令：
$ git pull 起源大师
事实：
两者都用于从远程存储库下载新数据。
例如，最近对您的远程存储库进行了更改，您希望将它们合并到您的本地副本中。 你有几个选择； 从远程获取更改的两个最常见的操作是 Git pull 和 Git fetch。
拿来：
拉：
Git Pull 比 git fetch 更好，因为它具有两个命令的功能。 但是，与 Git Pull 相比，Git Fetch 被认为更安全。
拿来
$ git fetch origin
git fetch 仅从远程存储库下载新数据 - 但它不会将任何这些新数据集成到您的工作文件中。 Fetch 非常适合对远程存储库中发生的所有事情进行全新的了解。 由于其“无害”的性质，您可以放心：fetch 永远不会操纵、破坏或搞砸任何东西。 这意味着您永远无法获取足够的频率。
拉
$ git pull origin master
相比之下，使用 git pull 的目的不同：使用远程服务器的最新更改更新当前的 HEAD 分支。 这意味着拉取不仅下载新数据； 它还直接将其集成到您当前的工作副本文件中。
事实：
两者都用于从远程存储库下载新数据。
为什么需要这些命令？
例如，您的远程存储库最近发生了更改，您需要将它们包含在本地副本中。 您在这里有几个选择； 对遥控器进行更改的两个最常见的选项是 Git pull 和 Git fetch。
需要考虑的要点：
拿来：
拉：
我的意见：
Git Pull 比 git fetch 更好，因为它执行两个命令。 但是，与 Git Pull 相比，Git Fetch 被认为更安全。
一个 git 存储库包含不可变的数据 blob 和一些可变的指针/引用/名称（我们称它们为分支，HEADS）以提高可用性（理论上，git 可以是一个纯粹的 append-only 存储，只能通过提交哈希访问）。
不可变的 blob 通常最终总是在所有贡献者之间共享。 每个开发人员在他的机器上都有所有这些的副本。
git fetch将最新的 blob 和远程可变文件下载到您的机器上。
它不会更改您的可变文件，也不会创建任何以前不存在的 blob。
git pull是git fetch然后是git merge 。 git merge创建以前从未存在于远程存储库中的新 blob，并更新您的可变文件（您的引用）。
git fetch将告诉本地 git 从原始文件中retrieve the latest meta-data信息(No file transferring) 。
git pull = git 提取并从远程存储库中获取（复制）所有更改。 (Includes file transferring)
git pull也尝试与本地更改合并。
拿来
git fetch 实际上只从远程存储库下载新数据 - 但它不会将任何这些新数据集成到您的工作文件中。 Fetch 非常适合获取远程存储库中发生的所有事情的全新视图。 由于它的“无害”特性，您可以 rest 放心：fetch 永远不会操纵、破坏或搞砸任何东西。
拉
相比之下，git pull 用于不同的目标：使用来自远程服务器的最新更改更新当前的 HEAD 分支。 这意味着 pull 不仅下载新数据； 它还直接将其集成到您当前的工作副本文件中。
'git remote update'，'git fetch'和'git pull'有什么区别？
[英]What is the difference between 'git remote update', 'git fetch' and 'git pull'?
git pull 和 git fetch + git rebase 有什么区别？
[英]What is the difference between git pull and git fetch + git rebase?
`git lfs fetch`、`git lfs fetch --all` 和 `git lfs pull` 有什么区别？
[英]What is the difference between `git lfs fetch`, `git lfs fetch --all`, and `git lfs pull`?
TortoiseGit：“Git Sync”、“Fetch”和“Pull”有什么区别？
[英]TortoiseGit: What's the difference between “Git Sync”, “Fetch” and “Pull”?
`git fetch` 然后 `git rebase` 和 `git pull --rebase` 有什么区别？
[英]What's the difference between `git fetch` then `git rebase`, and `git pull --rebase`?
git pull，git fetch + merge和git rebase之间的区别
[英]Difference between git pull, git fetch+merge and git rebase
“ git subtree pull”和“ git pull -s subtree”有什么区别
[英]What is the difference between “git subtree pull” and “git pull -s subtree”
声明:本站的技术帖子网页，遵循CC BY-SA 4.0协议，如果您需要转载，请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.