当前回答
重要的是,将设计理论与SVN这种较传统的源控制工具的理论加以对比。
Subversion 是用客户端/ 服务器模型设计和构建的。 服务器是一个单一的仓库, 有几个客户可以从服务器上获取代码, 工作, 然后将其发送到服务器 。 假设客户总是可以在服务器需要操作时与服务器联系 。
Git 的设计是为了支持一个更分散的模型,而不需要一个中央存储库(尽管如果您愿意,您肯定可以使用一个)。 Git 的设计也是为了让客户和“服务器”不必同时上网。 Git的设计是为了让不可靠的链接上的人可以通过电子邮件交换代码,甚至可以。可以完全断开工作,烧掉CD,通过 git 交换代码。
为了支持此模型 git , 维持一个包含您的代码的本地仓库, 以及一个反映远程仓库状态的附加本地仓库。 通过保存远程仓库的副本, git 可以在本地找到所需的更改, 即使远程仓库无法到达 。 稍后当您需要将更改发送到其他人时, git 也可以从远程仓库已知的时间点将其转换为一组更改 。
git fetch是命令 上面写着"把我的远程仓库的本地副本更新到最新"git pull将远程存储库的更改 带到我保存自己代码的地方
通常为git pull这样做的方式是:git fetch以更新远程存储库的本地副本,然后将修改合并到自己的代码存储库中,并可能合并到工作副本中。
需要铭记的是,至少有至少三份三份工作站上的一个工程。 一个副本是您自己的存储库, 并有您自己的承诺历史。 第二个副本是您正在编辑和构建的工作副本。 第三个副本是您的远程存储库的本地“ cashed” 副本 。
其他回答
重要的是,将设计理论与SVN这种较传统的源控制工具的理论加以对比。
Subversion 是用客户端/ 服务器模型设计和构建的。 服务器是一个单一的仓库, 有几个客户可以从服务器上获取代码, 工作, 然后将其发送到服务器 。 假设客户总是可以在服务器需要操作时与服务器联系 。
Git 的设计是为了支持一个更分散的模型,而不需要一个中央存储库(尽管如果您愿意,您肯定可以使用一个)。 Git 的设计也是为了让客户和“服务器”不必同时上网。 Git的设计是为了让不可靠的链接上的人可以通过电子邮件交换代码,甚至可以。可以完全断开工作,烧掉CD,通过 git 交换代码。
为了支持此模型 git , 维持一个包含您的代码的本地仓库, 以及一个反映远程仓库状态的附加本地仓库。 通过保存远程仓库的副本, git 可以在本地找到所需的更改, 即使远程仓库无法到达 。 稍后当您需要将更改发送到其他人时, git 也可以从远程仓库已知的时间点将其转换为一组更改 。
git fetch是命令 上面写着"把我的远程仓库的本地副本更新到最新"git pull将远程存储库的更改 带到我保存自己代码的地方
通常为git pull这样做的方式是:git fetch以更新远程存储库的本地副本,然后将修改合并到自己的代码存储库中,并可能合并到工作副本中。
需要铭记的是,至少有至少三份三份工作站上的一个工程。 一个副本是您自己的存储库, 并有您自己的承诺历史。 第二个副本是您正在编辑和构建的工作副本。 第三个副本是您的远程存储库的本地“ cashed” 副本 。
最简单的说,git pull是否为 a 的git fetch续 续 agit merge.
git fetch更新您的远程跟踪分支refs/remotes/<remote>/。此操作可以随时安全运行,因为它不会改变您在refs/heads.
git pull本地分支提供其远程版本的最新信息,同时更新其他远程跟踪分支。
调自 Git 文档git pull:
git pull运行中git fetch使用给定参数,然后取决于配置选项或命令行的旗帜,将调用其中之一git rebase或git merge以便各处之间互相调和。
有必要记住,在任何特定机器的Git存储库工作时,存储库载有来自所有远程的所有分支的复制件,以及每个地方分支的复制件,你已经做了一些工作。
你可以看到这个使用git branch -a显示您所在的分支机构,包括master和所有遥控器的分支。
master
feature/my-feature-branch
remotes/origin/master
remotes/origin/my-feature-branch
remotes/another-remote-machine/master
remotes/another-remote-machine/my-feature-branch
上面我已指出 遥控遥控器的存在origin以另一个名称返回和另一个远程another-remote-machine.
注意 您不必在所有仓库中拥有每个分支的复制件 。 (remotes 和 local.) 它取决于您通过运行同步 。git pull, git push, git fetch,来自不同的机器 / 仓库 所涉及的。
好,这里有一些关于git pull和git fetch这样你就能理解 实际的差别 用几个简单的字来说获取获取最新数据, 但代码不会更改, 也不会干扰您当前的本地分支代码, 但是,拉拉拉获取代码更改并合并您的本地分支, 阅读以获得更多关于每个代码的细节 :
git 获取 git 获取
全部下载refs 参考和对象和任何新的分支 到您的本地仓库...
从一个或多个其他仓库获取分支和/或标签(统称“refs”),以及完成历史所需的物件。远程跟踪分支得到更新(关于控制这种行为的方法,见下文说明)。
默认情况下, 任何标记指向所获取历史的标记也会被获取; 效果是获取标记指向您感兴趣的分支。 此默认行为可以通过使用 -- tags 或 -- no-tags 选项或通过配置远程.... tagOpt 来更改。 通过使用重新检查, 明确获取标记, 您可以将标记指向您感兴趣的分支, 也可以获取标记指向您感兴趣的分支 。
git 抓取可同时从一个命名的仓库或 URL 或从多个仓库获取,如果给出了,并且有远程。 在配置文件中输入 。 (见 git- config)1).
当没有指定远程时, 默认会使用来源远程, 除非为当前分支配置了上游分支 。
所抓取的参考文献的名称,连同它们指向的对象名称,都写到.git/FETCH_HEAD。此信息可用于脚本或其他 git 命令, 如 git- pull 。
git 拉
它将应用来自偏远会 议 日 和 排当前分支当前分支当地...
包含从远程仓库到当前分支的更改。 在默认模式中, git 拉动是 Git 获取的速记, 之后是 git 合并 FETCH_HEAD 。
更精确地说, git pull 运行 Git 获取带有给定参数的 git 并调用 git 合并, 将回收的分支头合并到当前分支。 如果使用 -- rebase, 它会运行 git 重基而不是 git 合并 。
应该是传递到 Git-fasser 的远程仓库的名称1。可以指定任意的远程参考文献(例如,标签的名称),甚至可以指定具有相应的远程跟踪分支(例如,参考文献/标题/)的参考文献集。备注/备忘/发源/发源/发源/发件人:),但通常是远程存储库中的分支的名称。
以 git-branch -- track 设定的当前分支的“ 远程” 和“ 合并” 配置的默认值, 并从中读取 。
我还创造了视觉显示您如何在下面git fetch和git pull携手合作...
简单说,如果你打算跳上飞机 没有任何互联网连接... 在离开之前,你可以做git fetch origin <branch>。它会将所有更改带入您的计算机,但会将其与您的本地开发/工作空间区分开来。
在飞机上,您可以对本地工作空间进行修改,然后将其与您先前所获取的合并,然后解决潜在的合并冲突,而无需与互联网连接。除非有人做了新建新远程仓库的更改 :git push origin <branch>去拿你的咖啡来
从这美妙的阿特拉斯教程:
缩略
git fetch命令从远程仓库下载文件,从远程仓库下载到本地仓库。获取是您想看到每个人 所做的事其它它与 SVN 的更新相似, 它让您看到中央历史的进展, 但并不迫使您将修改合并到仓库。 Git从现有本地内容中获取的内容,它有绝对当地发展工作不受到任何影响。获取的内容必须使用
git checkout命令。这使得获取安全的审查方式在将其与您本地的仓库整合之前能够兑现承诺。从远程仓库下载内容时,
git pull和git fetch用于完成任务的命令。您可以考虑git fetch两个命令的“ 安全” 版本。 它会下载远程内容, 但不更新本地仓库的工作状态, 使您目前的工作保持完整 。git pull是一个更积极的选项, 它会下载远程内容, 并立即执行 。git merge以创建新远程内容的合并承诺。如果您在进展中出现变化,这将引发冲突和启动合并冲突解决流程。
与git pull:
- 你没有得到任何孤立。
- 不需要明确检查 因为它暗含
git merge. - 合并步骤将影响您的本地发展,中 中 中 中 中 中导致冲突起因的冲突
- 基本上不安全 这是侵略性的
- 相 异
git fetch它只影响你.git/refs/remotesGit拉力会影响你.git/refs/remotes和.git/refs/heads/
嗯... 所以如果我不更新工作副本git fetch,然后我在哪里做改变? Git在哪里获得新承诺的商店?
最首要的重要问题,heads或remotes不存储新的承诺,他们只是指针承诺承诺。git fetch下载最新数据git 对象(blob, 树, 承诺。 要完全理解对象观察这个视频在 Git 内部),但只能更新您的remotes指指该分支的最新任务。 它仍然与您的工作副本隔开, 因为您的分支的指针在heads目录尚未更新。 它只会在merge/pull但还是在哪里?
在您的工程目录( 即您在哪里做git执行命令( do) :
ls。此选项将显示文件目录( T) 。 没有什么很酷的, 我知道 。现在做做
ls -a。这将显示点点文件,即从.这样您就可以看到一个名为 :.git.do do do Do
cd .git。这显然会改变你的目录。现在来有趣的部分; 做
ls。您将会看到目录列表。我们正在寻找refs。 do 做cd refs.有趣的是,看看所有目录里面有什么, 但是让我们集中关注其中两个。
heads和remotes. 使用cd检查他们内部。任何
git fetch它将更新该页面中的指针。/.git/refs/remotes目录。不会更新/.git/refs/heads目录。任何
git pull将首先完成git fetch更新项目并更新/.git/refs/remotes目录。然后它将会并且,还有与本地的本地合并,然后在/.git/refs/heads目录。
还可以找到一个非常良好的相关答案:"Gitt gets" 的地方本身在哪里?.
另外,搜索“斜缩缩写”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然后,你的地方小人物不会知道有2项承诺被添加。 它只会说:
Already on 'master'
Your branch is up to date with 'origin/master'.
但是,这是过时的,不正确的。因为Git会仅仅根据它所知道的,给你反馈。 新的承诺,它还没有撤销...
当地分行工作时,有没有办法看到在远距离进行的新变化?
有些国际开发实体(例如Xcode)超级聪明,使用git fetch并且可以说明您当前工作分支的远程分支中已经更改的代码行行。 如果该行被本地更改和远程分支修改, 那么该行会用红色附加注释。 这不是合并冲突。 这是 a潜在潜力合并冲突 。 这是一个提示, 您可以在进行合并冲突前先用它解决未来合并冲突 。git pull来自远程分支。
托盘提示 :
如果您已获取远程分支, 例如 :
git fetch origin feature/123
这将进入您的远程目录。 您的本地目录仍然无法访问它。 但是, 它简化了您在 DWIM 远程分支的校验( 做我的意思 ) :
git checkout feature/123
无需再做下列工作:
git checkout -b feature/123 origin/feature/123
将 " 更多 " 改为 " 更多 " 改为 " 更多 "在这里
缩略git 拉命令实际上是一个shortcut用于git 获取 git 获取排 排 排 排 排 排 排 排 紧 排 排git 合并或git 重新基数取决于您的配置配置命令。 您可以配置您的 Git 仓库, 这样git 拉是一个接驳物,然后是一个重置物。
推荐文章
- 如何从远程Git存储库中提取并覆盖本地存储库中的更改?
- Github:导入上游分支到fork
- Git单次修订的日志
- Git在不改变提交时间戳的情况下进行改基
- VS 2017 Git本地提交数据库。每次提交时锁定错误
- 如何在过去的一些任意提交之间注入一个提交?
- 从GitHub克隆项目后拉git子模块
- GitHub上的分叉和克隆有什么区别?
- 递归地按模式添加文件
- 我如何使用notepad++(或其他)与msysgit?
- 如何将现有的解决方案从Visual Studio 2013添加到GitHub
- Git存储库中的悬垂提交和blob是什么?它们来自哪里?
- 我如何简单地从我最新的git提交创建一个补丁?
- Git显示“警告:永久添加到已知主机列表”
- 我如何检索一个回购的远程git地址?
