这张图能帮上忙git pull基本上等于git fetch时当时git merge

重要的是,将设计理论与SVN这种较传统的源控制工具的理论加以对比。

Subversion 是用客户端/ 服务器模型设计和构建的。 服务器是一个单一的仓库, 有几个客户可以从服务器上获取代码, 工作, 然后将其发送到服务器 。 假设客户总是可以在服务器需要操作时与服务器联系 。

Git 的设计是为了支持一个更分散的模型,而不需要一个中央存储库(尽管如果您愿意,您肯定可以使用一个)。 Git 的设计也是为了让客户和“服务器”不必同时上网。 Git的设计是为了让不可靠的链接上的人可以通过电子邮件交换代码,甚至可以。可以完全断开工作,烧掉CD,通过 git 交换代码。

为了支持此模型 git , 维持一个包含您的代码的本地仓库, 以及一个反映远程仓库状态的附加本地仓库。 通过保存远程仓库的副本, git 可以在本地找到所需的更改, 即使远程仓库无法到达 。 稍后当您需要将更改发送到其他人时, git 也可以从远程仓库已知的时间点将其转换为一组更改 。

• git fetch是命令 上面写着"把我的远程仓库的本地副本更新到最新"

• git pull将远程存储库的更改 带到我保存自己代码的地方

通常为git pull这样做的方式是:git fetch以更新远程存储库的本地副本,然后将修改合并到自己的代码存储库中,并可能合并到工作副本中。

需要铭记的是,至少有至少三份三份工作站上的一个工程。 一个副本是您自己的存储库, 并有您自己的承诺历史。 第二个副本是您正在编辑和构建的工作副本。 第三个副本是您的远程存储库的本地“ cashed” 副本 。

• git pull获取承诺后尝试自动合并 。上下文敏感,因此所有被拉动的承诺都将合并为您目前活跃的分支。git pull自动合并承诺未经审查,而不先审查。。如果你不仔细管理自己的分支,你可能会遇到频繁的冲突。

• git fetch收集当前分支中不存在的目标分支的任何承诺,并将其存储在本地仓库中然而,它不会与您当前分支合并。如果您需要不断更新您的仓库,但正在研究一些更新文件时可能中断的文件。要将承诺整合到当前分支中,您必须使用git merge之后。

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

GitFlow 文档文档https://gist.github.com/peterdeweese/4251497

我花了一点点时间来理解有什么区别, 但这只是一个简单的解释。master在您的本地主机是分支 。

当您克隆一个仓库时, 将整个仓库获取到本地主机主机。 这意味着当您克隆一个仓库时, 您将会有一个源/ 主指示器HEAD指向同一方向HEAD.

当您开始工作并投入工作时,您将主指针推进到HEAD+ 你的承诺。但来源/总指针仍然指向你克隆时是什么。

因此,区别在于:

• 如果你做了git fetch它只会获取远程仓库中的所有更改( A) 。吉特胡布)并移动源/主指针到HEAD同时,你的当地分行长会继续指出它的位置。
• 如果你做了git pull,它基本上可以(如先前解释的)提取(如前所解释的)并合并对主分支的任何新修改,然后将指针移到HEAD.

这张图能帮上忙git pull基本上等于git fetch时当时git merge