git pull
和 和有什么区别git fetch
?
38 回答
用最简单的术语来说,git pull
agit fetch
后跟 a git merge
。
您可以git fetch
随时更新您的远程跟踪分支refs/remotes/<remote>/
。此操作永远不会更改您自己在 下的任何本地分支refs/heads
,并且在不更改工作副本的情况下可以安全地执行此操作。我什至听说有人git fetch
在后台定期运行 cron 作业(尽管我不建议这样做)。
Agit pull
是您要使用其远程版本更新本地分支,同时更新您的其他远程跟踪分支。
来自 Git 文档git pull
:
在其默认模式下,
git pull
是git fetch
后跟的简写git merge FETCH_HEAD
。
当你使用 时
pull
,Git 会尝试自动合并。它是上下文敏感的,因此 Git 会将所有拉取的提交合并到您当前正在处理的分支中。pull
自动合并提交而不让您先查看它们。如果你不仔细管理你的分支,你可能会遇到频繁的冲突。当您执行此操作时
fetch
,Git 会从目标分支收集您当前分支中不存在的所有提交,并将它们存储在您的本地存储库中。但是,它不会将它们与您当前的分支合并。如果您需要使存储库保持最新,但正在处理可能会因更新文件而中断的事情,这将特别有用。要将提交集成到您当前的分支中,您必须在merge
之后使用。
将 git 的设计理念与更传统的源代码控制工具(如 SVN)的理念进行对比非常重要。
Subversion 是使用客户端/服务器模型设计和构建的。有一个存储库是服务器,多个客户端可以从服务器获取代码,对其进行处理,然后将其提交回服务器。假设客户端在需要执行操作时始终可以联系服务器。
Git 旨在支持更分布式的模型,而不需要中央存储库(尽管您当然可以根据需要使用一个)。git 也被设计成客户端和“服务器”不需要同时在线。Git 的设计目的是让不可靠链接上的人们甚至可以通过电子邮件交换代码。可以完全断开连接并刻录 CD 以通过 git 交换代码。
为了支持这个模型,git 使用你的代码维护一个本地存储库,以及一个镜像远程存储库状态的附加本地存储库。通过在本地保存远程存储库的副本,即使无法访问远程存储库,git 也可以找出所需的更改。稍后当您需要将更改发送给其他人时,git 可以将它们作为一组更改从已知的时间点传输到远程存储库。
git fetch
是说“更新我的远程存储库的本地副本”的命令。git pull
说“将远程存储库中的更改带到我保存自己代码的地方。”
通常git pull
这样做是git fetch
为了更新远程存储库的本地副本,然后将更改合并到您自己的代码存储库和可能的工作副本中。
需要记住的是,您的工作站上通常至少有三个项目副本。一个副本是您自己的存储库,其中包含您自己的提交历史记录。第二个副本是您正在编辑和构建的工作副本。第三个副本是远程存储库的本地“缓存”副本。
这是奥利弗·斯蒂尔 (Oliver Steele) 对所有这些如何组合在一起的形象:
如果有足够的兴趣,我想我可以更新图像以添加git clone
和git merge
...
的一个用例git fetch
是,以下内容将告诉您自上次拉动以来远程分支中的任何更改......因此您可以在进行实际拉动之前进行检查,这可能会更改当前分支和工作副本中的文件。
git fetch
git diff ...origin
请参阅:https ://git-scm.com/docs/git-diff关于 diff 命令中的双点和三点语法
我花了一点时间来理解有什么区别,但这是一个简单的解释。master
在您的本地主机中是一个分支。
克隆存储库时,您会将整个存储库获取到本地主机。这意味着那时您有一个指向HEAD
和指向同一个的源/主指针HEAD
。
当您开始工作并提交时,您将主指针前进到HEAD
+ 您的提交。但是原点/主指针仍然指向克隆时的位置。
所以区别将是:
- 如果你这样做,
git fetch
它只会获取远程存储库 ( GitHub ) 中的所有更改并将源/主指针移动到HEAD
. 同时,您的本地分支主管将继续指向它所在的位置。 - 如果您执行 a
git pull
,它将基本上执行 fetch (如前所述)并将任何新更改合并到您的 master 分支并将指针移动到HEAD
.
简要地
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 步:在这里做一个可能更准确(例如在一个快速变化的 repo 上)git rebase origin
。请参阅另一个答案中的@Justin Ohms 评论。
另见: http: //longair.net/blog/2009/04/16/git-fetch-and-merge/
git-pull - 从另一个存储库或本地分支获取并合并 概要 git 拉… 描述 使用给定的参数运行 git-fetch,并调用 git-merge 来合并 将头检索到当前分支。使用 --rebase,调用 git-rebase 而不是 git-merge。 请注意,您可以使用 . (当前目录)作为 <repository> 拉取 来自本地存储库——这在合并本地分支时很有用 进入当前分支。 另请注意,用于 git-pull 本身和底层 git-merge 的选项 必须在用于 git-fetch 的选项之前给出。
如果你想合并历史,你会拉,如果你只是“想要 codez”,你会提取,因为有人在这里标记了一些文章。
您可以从远程存储库中获取,查看差异,然后提取或合并。
这是一个名为远程存储库origin
和一个名为master
跟踪远程分支的分支的示例origin/master
:
git checkout master
git fetch
git diff origin/master
git rebase origin master
好的,这里有一些关于git pull
and的信息git fetch
,所以你可以理解实际的区别......简单来说,fetch获取最新数据,但不是代码更改,不会弄乱你当前的本地分支代码,而是pull get代码更改并将其合并到您的本地分支,继续阅读以获取有关每个分支的更多详细信息:
获取
它将所有引用和对象以及任何新分支下载到您的本地存储库...
从一个或多个其他存储库中获取分支和/或标签(统称为“引用”),以及完成其历史所需的对象。远程跟踪分支已更新(有关控制此行为的方法,请参见下面的描述)。
默认情况下,任何指向正在获取的历史的标签也会被获取;效果是获取指向您感兴趣的分支的标签。可以通过使用 --tags 或 --no-tags 选项或配置 remote..tagOpt 来更改此默认行为。通过使用显式获取标签的 refspec,您也可以获取不指向您感兴趣的分支的标签。
git fetch 可以从单个命名存储库或 URL 或从多个存储库中获取,如果给定并且有一个遥控器。配置文件中的条目。(见 git-config 1)。
如果未指定远程,默认情况下将使用原始远程,除非为当前分支配置了上游分支。
获取的 refs 的名称以及它们指向的对象名称被写入 .git/FETCH_HEAD。脚本或其他 git 命令(例如 git-pull)可能会使用此信息。
git 拉
它会将远程的更改应用到本地的当前分支...
将来自远程存储库的更改合并到当前分支中。在其默认模式下,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
工作......
简短而简单的答案是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
. 除非你真的,真的知道你在做什么,否则我建议不要这样做。此警告来自, version的man
页面:git-pull
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.
获取遥控器镜像的一些主要优点是:
- 性能(滚动浏览所有提交和消息,而不试图通过网络挤压它)
- 关于本地 repo 状态的反馈(例如,我使用 Atlassian 的 SourceTree,它会给我一个灯泡,指示与原点相比我是提前还是落后提交。可以使用 GIT FETCH 更新此信息)。
GIT Fetch和GIT Pull之间的区别可以用以下场景来解释:( 请记住,图片胜于雄辩!,我提供了图片表示)
让我们举一个例子,您正在与您的团队成员一起处理一个项目。所以项目会有一个主分支,所有贡献者必须将它分叉到他们自己的本地存储库,然后在这个本地分支上修改/添加模块,然后推送回主分支。
因此,
当您在本地存储库上分叉主项目时,两个分支的初始状态A
将是这样的 - ( ,B
并且C
是项目的模块已经完成)
现在,您已经开始开发新模块(假设D
),当您完成D
模块后,您希望将其推送到主分支,但同时发生的情况是您的一位队友开发了新模块E
,F
并修改了C
.
所以现在发生的事情是您的本地存储库落后于项目的原始进度,因此将您的更改推送到主分支可能会导致冲突并可能导致您的模块D
发生故障。
为避免此类问题并与项目的原始进度并行工作,有两种方法:
1. Git Fetch -这将下载对 origin/main 分支项目所做的所有更改,这些更改不存在于您的本地分支中。并将等待 Git Merge 命令将已获取的更改应用到您的存储库或分支。
所以现在您可以在将文件合并到您的存储库之前仔细监控文件。由于 Modified ,您还可以D
根据需要进行修改C
。
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 本身不会在您的本地进行代码更改。您可以通过获取一次获取并查看来检查更新代码时;它不会改变的代码。然后合并...您将看到更改后的代码。
简单来说,如果您要在没有任何互联网连接的情况下跳上飞机……在出发之前,您可以这样做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、树、提交。要完全了解这些对象,请观看git internals 上的此视频),但只需更新您的remotes
指针以指向该分支的最新提交。它仍然与您的工作副本隔离,因为您的分支在heads
目录中的指针尚未更新。它只会在merge
/上更新pull
。但又在哪里?让我们来了解一下。
在您的项目目录中(即,您执行git
命令的位置)执行以下操作:
ls
. 这将显示文件和目录。没什么酷的,我知道。现在做
ls -a
。这将显示点文件,即以.
You 开头的文件,然后将能够看到一个名为:的目录.git
。做
cd .git
。这显然会改变你的目录。有趣的来了; 做
ls
。您将看到目录列表。我们正在寻找refs
。做cd refs
。查看所有目录中的内容很有趣,但让我们关注其中的两个。
heads
和remotes
。也cd
可以用来检查它们的内部。git fetch
您所做的任何/.git/refs/remotes
操作都会更新目录中的指针。它不会更新/.git/refs/heads
目录中的任何内容。Any
git pull
将首先执行git fetch
, update/.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)非常智能并且使用 a 的结果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
或它们。将在当前分支跟踪的远程分支上运行 fetch,然后合并结果。您可以使用查看远程分支是否有任何更新,而无需将它们与本地分支合并。git merge
git pull
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 允许在较新的提交之后应用按时间顺序较旧的提交。因此,在存储库之间传输提交的行为分为两个步骤:
将远程分支的新提交复制到本地仓库中此远程分支的副本。
(回购到回购操作)
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命令实际上是一个for shortcut
git fetch后跟git merge或git rebase命令,具体取决于您的配置。您可以配置您的 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
andgit 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是你的远程 repo 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
了解branches
.repository
大多git fetch
与git reset
. 例如,您希望将所有本地更改恢复为当前存储库状态。
git fetch --all // get known about latest updates
git reset --hard origin/[branch] // revert to current branch state
git拉
此命令更新您branch
的当前repository
branch
状态。让我们继续GitFlow
。多个功能branches
是分支,当您merged
想develop
为项目开发新功能时,您必须进行开发branch
并执行git pull
以获得当前状态develop
branch
按定义:
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 被认为更安全。