第3章 远程仓库
3.1 Git远程仓库是什么
Git远程仓库是位于网络上的仓库，该仓库中存放了你项目的各个版本。 （其实远程仓库也未必非得在网络上，所谓的远程仓库，不如直接理解为“另外一个仓库”而已”，测试的时候，甚至可以把所谓的远程仓库创建在你本地电脑上。）
3.2 Git远程仓库的作用
Git远程仓库的作用就是为了协作开发。同一个Git仓库，可以分布到不同的机器上。怎么分布呢？最早，肯定只有一台机器有一个原始版本库，此后，别的机器可以“克隆”这个原始版本库，而且每台机器的版本库其实都是一样的，并没有主次之分。
这些机器之间要经常把自己的修改推送给对方，这样比较麻烦，所以实际情况是只要找一台电脑充当服务器的角色，每天24小时开机，其他每个人都从这个“服务器”仓库克隆一份到自己的电脑上，并且各自把各自的提交推送到服务器仓库里，也从服务器仓库中拉取别人的提交。不过要知道这个服务器在Git中不是必须的，它只是为了方便交换数据。
我们没有必要自己搭建一个git服务器，进而在其上创建一个远程仓库。因为这个世界上有个叫Gitee的神奇的网站，这个网站就是提供Git仓库托管服务的，所以，只要注册一个Gitee账号，就可以免费获得Git远程仓库。（如果还没有Gitee的账户，现在就申请一个吧）。 注意，Gittee是免费的，但是如果一个项目的参与者，超过5个就要收费。
3.3 克隆Git远程仓库
当远程仓库已经存在，且本地仓库不存在时，我们可以直接把远程仓库克隆下来，克隆之后，就出现了一个与远程仓库关联好的本地仓库。
3.3.1 创建远程仓库
Gitee已经告诉我们，没有本地仓库和已有本地仓库分别要如何做，如下：
注意，git push命令要执行的前提是，本地仓库至少有一次提交。
3.3.2 克隆远程仓库
创建git workspace文件夹，在其中再创建andy和eason两个子文件夹模拟俩个机器
在andy文件夹中克隆远程仓库：
在eason文件夹中克隆远程仓库：
3.3.3 查看远程仓库
键入以下命令：
git remote -v
可以看到：
以上输出展示了与本地仓库关联的远程仓库的名字：origin，以及从origin这个远程仓库拉取数据的url，还有向origin这个远程仓库推送数据的url。注意，通过克隆方式关联的远程仓库名字，总是默认为origin。
3.3.4 推送提交
先在andy的本地仓库完成一个提交
然后推送到远程仓库origin：
git push origin master
刷新远程仓库：
3.3.5 拉取修改
此时在eason文件夹中，还没有index.html
拉取修改
注意，eason拉取的是修改而不是文件。意思是，eason把远程仓库中的修改拉取完毕以后，在本地对index.html又做了一些修改，结果eason又不想要这些修改了，如果希望通过再次执行“git pull”来拉取远程仓库的index.html文件，是无济于事的，因为“git pull”拉取的是修改而不是文件！如下：
要放弃工作区中的修改，执行以下命令即可：
git restore index.html
3.4 关联远程仓库
当远程仓库已经存在，本地仓库也已经存在，在该本地仓库没有关联远程仓库时，我们可以通过git命令让该本地仓库关联上远程仓库。
3.4.1 创建本地仓库
创建G.E.M文件夹，并将其初始化为一个git仓库
此时键入以下命令：
git remote -v
会发现该本地仓库并没有关联任何远程仓库
3.4.2 关联远程仓库
关联远程仓库的命令如下：
git remote add foo https://gitee.com/gapper/learn-git.git
注意，手动关联远程仓库的时候，可以自己指定远程仓库的名字，比如上面的foo就是自定义的远程仓库的名称。
3.4.3 拉取修改
此时G.E.M已经关联了learn-git远程仓库，就可以开始拉取其中的修改了：
git pull
结果，我们发现，无法拉取，这是因为，通过手动关联远程仓库的方式，并没有关联本地分支与远程分支！
可以通过以下命令查看远程仓库的详细信息：
git remote show 远程仓库名
有两种方式可以解决这个问题：
1. 在进行"git pull"的同时，临时指定本次分支和远程分支的关系
git pull <remote> <branch>
2. 仅仅只关联本地分支和远程分支，并不会进行"git pull"操作
git branch --set-upstream-to=foo/<branch> master
这里采用第一种方式：
3.3.4 解除关联
git remote remove foo
3.4.5 对比：
手动关联（不推荐） | git clone（推荐） | |
远程仓库在本地的名字 | 自己定义 | 默认为orign |
关联分支 | 手动关联 | 自动关联了本地仓库的master分支与远程仓库的master分支 |
git pull | 手动执行git pull | 自动执行git pull |
3.5 冲突
3.5.1 冲突发生的条件
我们已经知道，将本地仓库的修改推送给远程仓库的命令是：
git push
当andy和eason这两个小伙伴同时执行了"git pull"，且先后进行了“git push”，则后一个执行了"git push"的小伙伴就是倒霉蛋了！他的"git push"将会被拒绝。假设是eason是后一个执行"git push"的，此时eason的"git push"就会被拒绝！这是为了防止eason的修改覆盖了andy的修改。
如下：
3.5.2 解决冲突
当冲突在eason这一方发生后，eason需要先执行“git pull”，把andy的修改拉取下来，此时andy的修改、eason的修改全部都存在于index.html中了：
经过andy和eason两个人的商讨后，最终共同决定修改index.html内容如下：
此时，冲突已经解决。也就是在冲突发生后，先执行git pull，再git add，再git push就可以成功push了。
3.5.3 建议
我在此建议，每次要进行git push之前，一定要先进行一次git pull的执行。让git pull先把远程仓库中最新的修改拉取到本地，如果有冲突就解决，然后再进行push。
有些同学可能会担心，在git push之前，先进行git pull的话，远程仓库会把本地的新修改给覆盖了，这是不会发生的，此时git会提示我们合并代码的。
注意，以上的这种处理冲突的方式，其实这并不是实际开发中的工作流程，更加真实的开发流程，在下一章。
3.6 Git Aliases（自学）
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
