git命令 远程

pull & push Git仓库

克隆远程仓库git clone

现在用网站来对远程仓库进行可视化操作变得越发流行了(像 Github 或 Phabricator), 但远程仓库永远是这些工具的顶梁柱, 因此理解其概念非常的重要!

git clone 命令在真实的环境下的作用是在本地创建一个远程仓库的拷贝（比如从 github.com）。

远程分支

远程分支有一个命名规范 —— 它们的格式是:

<remote name>/<branch name>

因此，如果你看到一个名为 o/master 的分支，那么这个分支就叫 master，远程仓库的名称就是 o。

大多数的开发人员会将它们主要的远程仓库命名为 origin，并不是 o。这是因为当你用 git clone 某个仓库时，Git 已经帮你把远程仓库的名称设置为 origin 了

不过 origin 对于我们的 UI 来说太长了，因此不得不使用简写 o 😃 但是要记住, 当你使用真正的 Git 时, 你的远程仓库默认为 origin!

当 o/master 分支添加新的提交时 o/master 也不会更新。这是因为 o/master 只有在远程仓库中相应的分支更新了以后才会更新。

从远程仓库获取数据git fetch

git fetch 完成了仅有的但是很重要的两步:

从远程仓库下载本地仓库中缺失的提交记录
更新远程分支指针(如 o/master)

git fetch 实际上将本地仓库中的远程分支更新成了远程仓库相应分支最新的状态。

如果你还记得上一节课程中我们说过的，远程分支反映了远程仓库在你最后一次与它通信时的状态，git fetch 就是你与远程仓库通信的方式了！希望我说的够明白了，你已经了解 git fetch 与远程分支之间的关系了吧。

git fetch 通常通过互联网（使用 http:// 或 git:// 协议) 与远程仓库通信。

git fetch 并不会改变你本地仓库的状态。它不会更新你的 master 分支，也不会修改你磁盘上的文件。你可以将 git fetch 的理解为单纯的下载操作。

从远程仓库获取数据git pull

git pull 就是 git fetch 和 git merge 的缩写
git pull --rebase 就是 git fetch 和 git rebase 的缩写

上传数据到远程仓库git push

git push 负责将你的变更上传到指定的远程仓库，并在远程仓库上合并你的新提交记录。一旦 git push 完成, 你的朋友们就可以从这个远程仓库下载你分享的成果了！

注意 —— git push 不带任何参数时的行为与 Git 的一个名为 push.default 的配置有关。它的默认值取决于你正使用的 Git 的版本，但是在教程中我们使用的是 upstream。 这没什么太大的影响，但是在你的项目中进行推送之前，最好检查一下这个配置。

偏离的提交历史

如果多人协作开发，很容易发生代码冲突，导致上传失败。
解决方式：

• rebase（希望线性历史记录）/merge（希望还原真实开发顺序）的方式，先和远程仓库当前版本同步，然后再上传
• 手动合并分支（一般在高级的IDE中较为实用）

origin和它的周边 – 远程仓库的高级操作

推送主分支

在大型项目中开发人员通常会在（从 master 上分出来的）特性分支上工作，工作完成后只做一次集成。这跟前面课程的描述很相像（把 side 分支推送到远程仓库），不过本节我们会深入一些.

但是有些开发人员只在 master 上做 push、pull —— 这样的话 master 总是最新的，始终与远程分支 (o/master) 保持一致。

所以，多人参与的master分支会存在远程和本地都更新了历史记录的情况。这就需要通过git pull或git pull --rebase进行本地的同步。

合并远程仓库

为了 push 新变更到远程仓库，你要做的就是包含远程仓库中最新变更。意思就是只要你的本地分支包含了远程分支（如 o/master）中的最新变更就可以了，至于具体是用 rebase 还是 merge，并没有限制。

所以，工作时可以结合实际需求使用。

远程跟踪分支

master 与 o/master 是相关的。

pull 操作时, 提交记录会被先下载到 o/master 上，之后再合并到本地的 master 分支。隐含的合并目标由这个关联确定的。
push 操作时, 我们把工作从 master 推到远程仓库中的 master 分支(同时会更新远程分支 o/master) 。这个推送的目的地也是由这种关联确定的！

master 和 o/master 的关联关系就是由分支的“remote tracking”属性决定的。master 被设定为跟踪 o/master —— 这意味着为 master 分支指定了推送的目的地以及拉取后合并的目标。

当你克隆时, Git 会为远程仓库中的每个分支在本地仓库中创建一个远程分支（比如 o/master）。然后再创建一个跟踪远程仓库中活动分支的本地分支，默认情况下这个本地分支会被命名为 master。

克隆完成后，你会得到一个本地分支。这样做对于本地仓库和远程仓库来说，都是最佳选择。这也解释了为什么会在克隆的时候会看到下面的输出：

local branch “master” set to track remote branch “o/master”

可以让任意分支跟踪 o/master, 然后该分支会像 master 分支一样得到隐含的 push 目的地以及 merge 的目标。 有两种方法设置这个属性：

• 初始化分支并且追踪远程目标分支git checkout -b <初始化分支名称> <远程目标分支名称>例git checkout -b totallyNotMaster o/master
• 已存在的本地分支追踪远程目标分支git branch -u <远程目标分支名称> <本地分支名称>例git branch -u o/master foo如果当前就在 foo 分支上, 还可以省略 foogit branch -u o/master

git push的参数

语法：git push <remote> <place>
<remote>参数为origin
<place> 参数有两种使用方式。我们稍后会深入其中的细节, 先看看例子, 这个命令是:

git push origin master

把这个命令翻译过来就是：

切到本地仓库中的“master”分支，获取所有的提交，再到远程仓库“origin”中找到“master”分支，将远程仓库中没有的提交记录都添加上去，搞定之后告诉我。

我们通过“place”参数来告诉 Git 提交记录来自于 master, 要推送到远程仓库中的 master。它实际就是要同步的两个仓库的位置。

需要注意的是，因为我们通过指定参数告诉了 Git 所有它需要的信息, 所以它就忽略了我们所检出的分支的属性！

place参数详解

如果来源和去向分支的名称不同。比如你想把本地的 foo 分支推送到远程仓库中的 bar 分支。只需要用冒号 : 将二者连起来就可以了：

git push origin refspec
同
git push origin <source>:<destination>

<source>:<destination>参数实际的值是个 refspec，“refspec” 是一个自造的词，意思是 Git 能识别的位置（比如分支 foo 或者 HEAD~1）例git push origin off^:bar

git fetch的参数

git fetch 的参数和 git push 极其相似。他们概念相同，方向相反。

git fetch origin refspec

Git 会到远程仓库的 foo 分支上，然后获取所有本地不存在的提交，放到本地的 o/foo 上。意思就是删除远程仓库的分支。它不会更新你的本地的非远程分支, 只是下载提交记录（这样, 你就可以对远程分支进行检查或者合并了）。如果 git fetch 没有参数，它会下载所有的提交记录到各个远程分支

没有source的source

git push origin :side # 会删除远程仓库的side分支
git fetch origin :bugFix # 会在本地创建一个新的分支

git pull的参数

以下命令在 Git 中是等效的:

git pull origin foo 相当于：git fetch origin foo; git merge o/foo

最终合并到本地的检出位置，无论我们当前检出位置是哪里。

还有…
git pull origin bar~1:bugFix 相当于：git fetch origin bar~1:bugFix; git merge bugFix

git pull 实际上就是 fetch + merge 的缩写, git pull 唯一关注的是提交最终合并到哪里（也就是为 git fetch 所提供的 destination 参数）