Git远程操作

目录

理解分布式版本控制系统

理解集中式版本控制系统

远程仓库

认识远程仓库

新建远程仓库

克隆远程仓库

向远程仓库推送

拉取远程仓库

忽略特殊文件

---

        截止前两章我写的git的相关操作，无论是add添加到暂存区以及commit提交到某个分支，这些都是在本地操作的，即在我们自己的计算机上。但是Git实际上是分布式版本控制系统！这是什么意思呢，以及如何向远端仓库提交或拉去自己的代码呢？本章将详细介绍Git的远程操作。

理解分布式版本控制系统

        分布式可以简单理解为，我们每个⼈的电脑上都是⼀个完整的仓库(版本库)，这样你⼯作的时候，就不需要联网了，因为仓库(版本库)就在自己的电脑上。既然每个人电脑上都有⼀个完整的版本库，那多个⼈如何协作呢？比方说你在自己电脑上改了文件A，你的同事也在他的电脑上改了文件A，这时，你们俩之间只需把各自的修改推送给对⽅，就可以互相看到对方的修改了。

        分布式版本控制系统的安全性要高很多，因为每个⼈电脑⾥都有完整的版本库，同事A的电脑坏掉了不要紧，修好后重新从同时B那里复制⼀份就可以了。        

但是有个问题，只是单纯的两台主机推送修改，如果两台主机不在同一局域网内，电脑互相访问不了；也有可能你同事B今天没来，没有开机，同事A也无法得到同事B中的代码，非常的麻烦。而且如果同事A和同事B的电脑同时坏掉了，那么代码就彻底丢失了，一切都得重头再来。

        最好的办法是有一台充当“中央服务器”的电脑，24小时不关机，也来存储版本库，方便"交换" 大家的修改，没有它大家一样干活，只不过就会造成刚才上面所说的交换不方便的问题。

        有了这个"服务器"后，这个时候A电脑坏了修好了但没有数据了，B电脑也不在，也没有关系，直接从这台"中央服务器"中拉取版本库的代码即可，这样即使A和B的代码数据都丢失了也没关系，我们直接从中拉取代码即可。

        这台“中央服务器”我们便可以称作是远程仓库。

理解集中式版本控制系统

        先说集中式版本控制系统。简单的说就是，版本库是集中的存放于中央服务器的。工作的时候，先要去中央服务器里领取最新的版本，然后再开始干活。干完活在将自己的版本上传到中央服务器。

        就好比要改一本书，先要从图书馆里将书籍借阅出来，然后改完了之后，在将图书归还给图书馆。然后别人看到的就是最新的版本了。

        而分布式管理是将这本图书打印一份，让人手一本，这样每个人都可以看到，而且可以做修改。

分布式管理系统的缺点

缺点:

一但没有网或者网络不好的话，自己写的东西就很难得传上去。别人也不能及时的看到。简单的说就是没有网就不能使用。

---

二者的区别：

分布式每个人的电脑上都可以直接拷贝完整的代码版本。而集中式只能拷贝自己需要的。

分布式的服务器挂掉之后，不会影响工作因为是在本地。而集中式的服务器挂掉之后，根本就没法进行工作。

当然分布式管理系统不仅只有不用联网这个优势，还有git强大的分支管理等功能。当然各有优缺点，选择适合的场景使用(不过我感觉分布式相比集中式没有缺点~~~)

---

 

远程仓库

认识远程仓库

        Git 是分布式版本控制系统，同⼀个Git仓库，可以分布到不同的机器上。怎么分布呢？最早，肯定只有⼀台机器有⼀个原始版本库，此后，别的机器可以“克隆”这个原始版本库，⽽且每台机器的版本库其实都是⼀样的，并没有主次之分。
        你肯定会想，至少需要两台机器才能玩远程库不是？但是我只有⼀台电脑，怎么玩？
其实⼀台电脑上也是可以克隆多个版本库的，只要不在同⼀个⽬录下。不过，现实⽣活中是不会有⼈这么傻的在⼀台电脑上搞⼏个远程库玩，因为⼀台电脑上搞⼏个远程库完全没有意义，⽽且硬盘挂了会导致所有库都挂掉，所以我不推荐你在⼀台电脑上怎么克隆多个仓库。
        实际情况往往是这样，找⼀台电脑充当服务器的⻆⾊，每天24小时开机，其他每个⼈都从这个“服务器”仓库克隆⼀份到⾃⼰的电脑上，并且各⾃把各⾃的提交推送到服务器仓库⾥，也从服务器仓库中拉取别⼈的提交。
        完全可以自己搭建⼀台运行 Git 的服务器，不过现阶段，为了学 Git 先搭个服务器绝对是小题大做。好在有个叫  GitHub 的的⽹站，从名字就可以看出，这个网站就是提供Git仓库托管服务的，所以，只要注册⼀个GitHub账号，就可以免费获得Git远程仓库。

        但是GitHub是国外网站，访问速度比较慢，所以我们一般用码云(gitee)来托管代码，下面我们将从零开始 讲解如何使用gitee远程仓库。

新建远程仓库

1.首先我们打开gitee网站，注册或登录自己的账号。

2.登录完成后，我们点右上角的加号，新建仓库

 3.填写仓库的基本信息

当我们填好仓库名称后，仓库的路径它也会自动给我们添加好；

然后你可以选择开源或私有，开源之后，所有访客都可以看到你的仓库；私有只有你个人才可以看到；

然后下面有三个选项，分别为初始化仓库、设置模板、选择分支模型。大家按需选择即可。

4.创建完成后如下：

这里的master分支是远程仓库中的master分支，不是我们本地的。

这三个文件分别是.gitee，README.en.md和README.md.

先说README.md.这个文件是用来告诉访客这个仓库是用来做什么的，以及一些代码的实现细节等等，需要我们自己编写。

README.en.md是英文版的README.md，道理同样，可写可不写。

打开.gitee文件，里面有这两个文件：

一个是ISSUE的模板文件，什么意思呢，我们打开：

这是用来做什么的呢？(本来写了挺多，但感觉步骤太冗余了，而且真正企业中也用不到，这里就直接说了）

        这个相当于是是 访客与开源者 的一个信息交流的媒介，比如一个开源者将项目开源了，你也看到了它的开源代码，但是很快你就发现了这个代码中有一个隐藏的bug需要修复，这个时候你需要告诉开源者，那如何联系开源者呢？开源者又如何确定你身份呢？于是就有了Issues这个功能，用来提交一些问题的地方：

你可以在左编辑栏写bug的具体内容，在右编辑栏对该内容进行一些属性设置，包括负责人，抱歉严重程度等等。

创建完成后，你会看到下面这样的场景：

 右边的状态是开源者设置的，你如果认为这个bug是错误的，不存在的，可以将状态设置为已关闭，如果修复好了，可以设置成已完成。一切都是自己的抉择。

---

那么.gitee中第二个文件，PULL_REQUEST是做什么的，有什么用呢？

        当开发人员有一个dev分支需要合并(merge)到master主分支上时，作为管理人员的你，可以让他直接合并吗？答案是肯定不行的，万一我们master分支上的代码跑的挺好的，合上dev分支后出现报错或者大量错误怎么办，在业务中会影响多少客户，损失不可想象。

        因此若要将dev分支合并到master分支上时，需要开一个PR(即pull requests)即合并申请单，写上合并的原因及功能或其他的，然后交给管理员，管理员确认无误同意后，才能将将dev 合并到master分支上。

 这里左边是想要合并的dev分支(我还没有创建，所以显示选择不同分支，等下演示)，右边是目标分支，是我们想合并到的分支如master。

---

克隆远程仓库

我们想将gitee远程仓库代码克隆到本地，该如何做呢？

克隆/下载远端仓库到本地，需要使⽤ git clone 命令，后⾯跟上我们的远端仓库的链接，远端仓库
的链接可以从仓库中找到：选择“克隆/下载”获取远程仓库链接.

        SSH协议和 HTTPS协议是 Git 最常使用的两种数据传输协议。SSH 协议使⽤了公钥加密和公钥登陆机制，体现了其实用性和安全性，使用此协议需要将我们的公钥放上服务器，由 Git 服务器进行管理。使⽤HTTPS方式时，没有要求，可以直接克隆下来。

然后我们打开xshell，登录我们的云服务器，然后在任一目录下，但一定不要是带有版本库的目录，例如我在gitcode中初始化了版本库，此时我们一定不要再在gitcode目录中clone代码了。我此时选择与gitcode同级目录下拷贝：

此时我们便将仓库中的内容clone下来了。

当然也可以进行ssh协议进行克隆，但需要在gitee上配置公钥，具体配置步骤我就不详细说了，可以从网上看其他详细配置教程。 

向远程仓库推送

本地已经 clone 成功远程仓库后，我们便可以向本地仓库中提交内容，例如新增⼀个 file.txt ⽂件，然后添加一行内容：

        提交时要注意，如果我们之前设置过全局的name和e-mail，这两项配置需要和gitee上配置的⽤户名和邮箱⼀致，否则会出错; 或者从来没有设置过全局的name和e-mail，那么我们第⼀次提交时也会报错.

这就需要我们重新配置下了，同样要注意需要和 gitee 上配置的用户名和邮箱⼀致。

配置的用户名需要和@后面的内容相同，

邮箱需要与邮箱管理中的邮箱相同：

配置代码： 

---

到这⾥我们已经将内容提交⾄本地仓库中，如何将本地仓库的内容推送⾄远程仓库呢，需要使⽤ git push 命令，
该命令⽤于将本地的分⽀版本上传到远程分支并合并，命令格式如下：

git push <远程主机名> <本地分⽀名>:<远程分⽀名>

# 如果本地分⽀名与远程分⽀名相同，则可以省略冒号：
git push <远程主机名> <本地分⽀名>

此时我们需要将本地master分支 推送到远程主机名origin(默认为origin) 中的master分支，所以代码可以这样写：

git push origin master:master

这样便成功推送到远程仓库中了，当然由于此时本地分支名和远程主机分支名一样，也可以省略冒号这样写：

git push origin master

 此时我们打开gitee，并查看仓库中的内容：

我们发现代码已经被推送到远程仓库了。打开file文件，也能看到对应的内容：

 

所以刚才的过程可以为如下图：

 

拉取远程仓库

当远程仓库代码 新与我们本地代码时，我们需要拉取远程仓库代码到本地，更新本地的代码。

什么情况会造成远程仓库代码 会比本地代码新呢？

假设有两个用户A和B，远程仓库此时有一个file文件，内容为aaa，假设此时A和B本地内容和远程主机一样，都是只有一个file文件，然后内容为aaa。

此时A对文件做了修改，比如新添加了一行bbb，然后commit提交到本地后，然后push到远程仓库了，此时的远程仓库代码为aaa bbb。

但是B此时file文件内容依然为aaa，所以此时B的代码就已经落后于远程仓库了，所以B需要拉取最新的远程仓库代码到本地，使用了git pull指令，具体使用方法为：

git pull <远程主机名> <远程分⽀名>:<本地分⽀名>

# 如果远程分⽀是与当前分⽀合并，则冒号后⾯的部分可以省略。
git pull <远程主机名> <远程分⽀名>

因为现在就我一个用户，我为了演示这个场景，直接在gitee上修改代码了，平时工作时千万不要这么做！

我新添加了一行hello，git pull，然后点击下方提交后，此时远程仓库代码已经新于我们本地的代码了。

 所以此时我们使用git pull 命令，将远程仓库拉取下来：

其中我拉取的命令使用了

git pull origin master

这是由于本地分支名和远程主机名一样，可以省略冒号后面的内容。

如果本地分支名和远程主机名一样，也可以直接使用

git pull

便可以将远程仓库代码拉取下来。

注意：pull操作其实分为两步：拉取+合并分支！

以上流程就为蓝色部分内容：

忽略特殊文件

        在⽇常开发中，我们有些⽂件不想或者不应该提交到远端，⽐如保存了数据库密码的配置⽂件，那怎么让 Git 知道呢？在 Git ⼯作区的根⽬录下创建⼀个特殊的 .gitignore ⽂件，然后把要忽略的⽂件名填进去，Git 就会⾃动忽略这些⽂件了。不需要从头写 .gitignore ⽂件，gitee 在创建仓库时就可以为我们⽣成，不过需要我们主动勾选⼀下：

如果当时没有选择这个选择，在⼯作区创建⼀个也是可以的。⽆论哪种⽅式，最终都可以得到⼀个完整的 .gitignore ⽂件，例如我们想忽略以  .so  和 .ini结尾所有⽂件， 即提交时不要提交以.so 或.ini结尾的文件，.gitignore 的内容如下： 

 然后就是把.gitignore文件提交到远端：

这样文件就生效了。 此时当我们向add 以.so结尾的文件时，就出出现以下错误：

告诉我们如果想强制add 符合在.gitignore文件时，需要加上-f，此时我们加上-f:

此时发现我已经可以提交到本地并推送到远端仓库了，此时我们打开远端仓库查看：

发现文件已经被提交上来了，至此.gitignore文件讲解至此结束。

到这里，git远程操作相关内容便讲解完了，加上前两节章的内容，基本上所有的git内容都已经讲解完毕，如果有不懂或者疑问的地方，欢迎评论区提问~