回报 :

谈到上述答案中的拉动和取回,我想分享一个有趣的把戏,

git Pull -- rebase

以上命令是我生命中最有用的命令 挽救了很多时间

在将您的新承诺推进到服务器之前, 请尝试此命令, 它会自动同步最新的服务器更改( 加上一个抓取 + 合并) , 并将您的承诺放在 Git 日志的顶部 。 无需担心手动拉动/ 合并 。

详情见:http://gitolite.com/git-pull-rebase

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

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

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

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

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

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

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

git 将代码从远程服务器拖动到您本地仓库的跟踪分支。 如果您的远程代码被命名为源代码( 默认) , 这些分支将位于源代码/ 内, 例如源代码/ 源代码/ 主管、 源代码/ mybranch-123 等 。 这些不是您当前的分支, 它们是服务器上这些分支的本地副本 。

git pull 进行 git 抓取, 但也同时将代码从跟踪分支合并到您当前本地版本的分支中。 如果您还没有准备好修改, 请先拨入 。

git pull 尝试在获取承诺后自动合并 。 这是上下文敏感, 所以所有被拉过的承诺都将合并到您当前活动的分支中 。 git pull 自动合并承诺而不让您首先审查它们。 如果您不小心管理您的分支, 您可能会遇到经常的冲突 。 git 获取从目标分支中收集当前分支中不存在的任何承诺, 并将其存储在您的本地仓库中 。 但是, 它不会与当前分支合并 。 如果您需要更新您的仓库, 这特别有用 。 如果您需要更新文件, 但它正在处理一些可能中断的任务 。 要将承诺整合到当前的分支中, 您以后必须使用 Git 合并 。

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

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

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

有时视觉表现会有所帮助。

调