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

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

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

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

Gitfreating是命令 上面写着"把我的远程仓库的本地副本更新到最新" git pull 说"把远程仓库的更改 传送到我自己的代码所在的地方"

通常情况下, git pull 将远程仓库的本地副本更新, 然后将更改合并到您自己的代码存储处, 并可能合并到您的工作副本 。

转移是记住您工作站上的项目通常至少有三个副本。 一个副本是您自己的存储库, 并有您自己的执行历史。 第二个副本是您编辑和构建的工作副本。 第三个副本是您本地的远程存储库“ 隐藏” 副本 。

您可以从远程仓库获取, 查看差异, 然后拉动或合并 。

这是被称作起源的远程存储库和名为“跟踪远程分支来源/主管”的分支的分支的一个例子:

git checkout master                                                  
git fetch                                        
git diff origin/master
git rebase origin master

用最简单的术语来说, git pull 是一个 Git 抓取, 然后是 git 合并 。

git 在 refs/ remotes/ <remote> / 下获取远程跟踪分支的更新。 此操作随时可以安全运行, 因为它不会在 refs/ head 下更改您的本地分支 。

git 拉动使当地的一个分支能够更新其远程版本,同时更新其他远程跟踪分支。

Git Pull 的 Git 文档 :

git pull 运行 git 获取带有给定参数的 Git 抓取, 然后根据配置选项或命令行旗帜, 将调用 git 重新基准或 Git 合并以调和不同的分支 。

以下是Oliver Steele的画面,

调

GIT Fetch 和 GIT Pull 之间的差异可以用以下情景来解释:(铭记图片比文字更响亮!

让我们举一个例子来说明您正在与团队成员一起开展一个项目。 因此,该项目将有一个主要分支, 所有贡献者都必须将该项目推到他们自己的本地仓库, 然后在这个本地分支上修改/ 添加模块, 然后推回主分支 。

因此,当您在本地存储库中将主要项目提前启动时, 两个分支的初始状态将像这样( A、 B和 C 是项目已经完成的模块) 。

调

现在,您已经开始开发新模块( 假设 D) , 当您完成 D 模块后, 您想要将其推进到主分支, 但与此同时, 您的队友之一开发了新的模块 E, F 和修改过的 C 。 因此, 现在发生的情况是, 您的本地仓库缺少项目初始进展的背后, 因此将您的更改推到主分支可能导致冲突, 并可能导致模块 D 出现故障 。

调

为了避免此类问题,并与项目的最初进展平行工作,有两种方式:

1. Git F抓取 - 这将下载对本地分支中不存在的源/ 主分支工程所做的全部更改。 并且将等待 Git 合并命令应用您仓库或分支的更改 。

调

现在您可以仔细监视文件, 然后将其合并到仓库。 如果需要修改 C, 您也可以修改 D 。

调

2. Git Pull - 这将更新您的本地分支, 使用源/ 主分支, 即它所做的是将 Git Fetch 和 Git 合并成一个组合, 但可能会引发冲突, 因此建议使用 Git Pull 并使用干净的复制件 。

调

此图形可能有用 。 git pull 基本上等于 Git 获取然后 git 合并

调