Git：远程操作

目录

理解分布式版本控制系统

创建远程仓库

克隆远程仓库__HTTPS

克隆远程仓库__SSH

向远程仓库推送

拉取远程仓库

忽略特殊文件

配置命令别名

理解分布式版本控制系统

我们目前所说的所有内容(工作区，暂存区，版本库等等)，都是在本地，也就是在你的笔记本或者计算机上，而我们的 Git 其实是分布式版本控制系统

我们前面所说的都是在一台服务器上操作，那么在实际操作过程中，我们几个开发人员肯定不可能围着一台电脑，你开发一会，我开发一会，这样就失去了多人协作的意义了

我们想要的效果是：我们让每一个人的电脑上，都拥有自己独立且完整的仓库，张三和李四的电脑上都有了一样的仓库，这时想要多人协作开发时，李四如果修改了某部分内容，就将修改的这部分内容推送给张三，此时张三就能够看到李四的改动了，同样的，张三修改了某部分代码，也可以推送给李四，李四也就能够看到张三的改动了

如果张三的电脑坏了，也不用担心，只要从李四的电脑上复制一份仓库的代码即可

但是有下面的两种情况出现时，依旧有问题：

• 如果两台电脑不在一个局域网内，相互访问不了，也是没有办法推动的
• 如果张三某一天生病了，并没有开自己的电脑，而李四的电脑刚好坏了，此时的仓库也是没有办法推送的

正是因为有上述所说的问题，这个版本也不是 Git 最终的版本

Git 给我们提供了一个中央服务器，让中央服务器保持 24 小时的开机状态，中央服务器是有一个仓库的，其余所有的服务器都是和中央服务器进行交互的，每一个服务器都克隆一份中央服务器的仓库克隆到自己的电脑上

此时在自己电脑上进行提交修改时，我们就可以将我们自己修改的内容提交到中央服务器里面，如果其他人想看修改的内容，其他人就可以从中央服务器中拉取修改的内容，此时就能够在自己的仓库中看到最新的代码

所以中央服务器得作用就是方便大家交换修改的，有了这个中央服务器就不怕是自己或者别人的电脑出问题，而导致仓库丢失的问题了，只要中央服务器不挂，代码就不会丢失

中央服务器又叫做远程仓库，因为这个中央服务器已经不在本地服务器上存储了

像我们所使用的 github/gitee 就是比较出名的大型的中央服务器仓库，在国内一般使用的是 gitee(码云)，因为在国内访问 github 是比较慢的

因此 Git 称为 分布式版本控制系统

创建远程仓库

新建仓库是比较简单的，首先打开 gitee，进行下面的操作：

在我们进入公司后，一个仓库对应的都是一个项目系统， 所以仓库名称一定是围绕系统要做什么来起名的，比如说我们是想进行 git 的教学，所以仓库名起为 remote-gitcode ，路径就会根据我们所起的仓库名称自动生成：

接下来介绍上述图片中的初始化仓库、设置模版、选择分支模型

初始化仓库

初始化仓库中可以选择我们的这个仓库所使用的语言是什么，后两个先不做解释 

设置模版

设置模版中，有上述三个模版，其中第一个 Readme 文件，就是别人点进我们的仓库，第一个能看到的文件，里面会详细说明这个仓库是干什么的，详细内容是什么
后面的 Issue模版文件和Pull Request模版文件 这里就先不介绍了，后面再说明，这里先将这三个模版文件勾选上

选择分支模型

分支模型有很多，这里先选择第一个单分支模型

下面点击创建，就会生成下面的界面
其中 README.md 是中文版的 README 文件，README.en 是英文版的 README 文件：

点击进 ReadMe 文件，会发现 gitee 自动生成的这个文件中，有介绍、软件架构、安装教程等部分，我们后期可以自行添加上去，可以让别人一点进 ReadMe 文件，就知道我们这个仓库的作用是什么：

在我们创建完毕仓库后，上面会有一个管理，点进去：

可以看到一个 gitee仓库，会有下面四种成员：

如果不懂这几种成员的含义，可以点击进 gitee 帮助中心，下面就详细介绍了每种成员的含义：

而我们刚刚还选择的那几个模版文件，是在 .gitee 中存在的，点击进入 .gitee：

首先点击 Issue，发现下面几个标题：

刚刚点击管理的那一行中，还有 Issues 和 Pull Requests 这两个选项，首先点击 Issues：

再点击有上面的 新建 Issue：

这三个就是我们刚刚点击 .gitee/Issue 文件中的内容，所以这个 Issue 文件的作用就是：
让我们有问题的人，和当前仓库的人员进行交流的地方， 也就是说，我们将我们的仓库设置为开源后，如果有其他人看到我们的开源仓库代码中的 bug，想要联系我们，不可能直接给我们打电话告诉我们吧，这显然不太合理

所以就采用这个的 Issue 文件，让发现 bug 的成员与我们仓库的管理者或是仓库的成员进行交流的地方，比如说发现了一个 bug，我们就新建一个 Issue：

接着点击下面的 创建，创建后 Issues 后面就有了一个问题了：

如果说我们将这个问题处理完毕了，就点击问题：

然后将这个状态改为 已完成或是已关闭 即可，此时就表明这个问题已经处理完毕了：

Pull Request

下面先点击 .gitee/Pull Request，观察 Pull Request 文件的内容：

前面的博客说到过，我们想进行开发时，肯定不是在 master 上开发的，而是在其他分支，例如创建一个 dev 分支上开发，当我们在 dev 分支上开发完后，是需要 master 分支进行 merge 的，也提到过这里的往 master 分支上 merge 的操作是非常危险的操作，因为我们并不能确定我们自己的代码没有问题，如果随便将自己的代码合并到 master 上，出现 bug 的话，那就可能会造成很大的损失

所以在实际开发过程中，开发者要提供一个 PR，也就是 Pull Request，也就是提供一个合并申请单，这个 合并申请单 中需要声明 dev 中有哪些功能，为什么要合并等原因，这个申请单就是给仓库管理员看的，一旦管理员同意了，我们才可以将自己的代码 merge 到 master 上去

点击 新建 PullRequest，下面就会出现 源分支 和 目标分支，我们就可以进行选择，选择完后就会出现一个申请单 

克隆远程仓库__HTTPS

想要克隆远程仓库，就需要点击这个：

点进去后，有下面几种 Git 提供给我们的数据传输的协议，最常使用的就是 HTTPS 和 SSH： 

• SSH：使用的是公钥加密和公钥登录的机制，体现的就是实用性和安全性，如果我们想要使用 SSH 提供的链接进行操作的话，我们必须要添加我们本地服务器上的公钥，存到 Git 的服务器上，Git 服务器就由码云平台代替，码云平台上肯定有一个地方可以配置我们自己本地服务器上的一个公钥的，到时候使用 SSH 协议的时候再来配置
• HTTPS：它提供的协议在克隆的时候是没有任何要求的，直接使用链接克隆即可，下面就先使用 HTTPS 这个协议

我们首先复制 HTTPS 协议提供的链接，然后在我们自己的云服务器上，执行 git clone + 链接 的操作
需要注意，克隆命令执行时不能在本地仓库中执行

克隆下来以后，在当前路径下就存在了 remote-gitcode，它对应的就是我们的远程仓库：

进入 remote-gitcode，发现有下面的几个文件：

• .git 就是版本库，也就是 Git 的一个仓库
• .gitee、README的中英文版，刚刚在码云上也看到了

克隆下来以后，状态如下：

远程仓库后面的 origin，就是远程仓库默认的仓库名，也可以执行 git remote 查看：

通过 git remote -v，可以观察本地仓库的权限，可以看到是有 推和拉 权限的：

如果远程仓库中存在本地仓库没有的，就可以 fetch 拉到本地仓库中
在本地修改完代码后，可以使用 push 权限，push 到远程仓库中

克隆远程仓库__SSH

使用 SSH 协议时，需要将本地服务器上的公钥，放到 Git 服务器上来进行管理才可以克隆成功

在码云平台上，点击设置，左边一栏安全设置中，就有 SSH公钥 这个设置：

点击进去后，如下所示：

下面我们先将刚刚克隆下来的使用 HTPPS 协议的 remote-gitcode 删除掉

接着我们不设置公钥，直接复制 SSH 的链接，克隆到我们的云服务器上，就会提示我们权限不足

出现上述问题，就是说明我们没有在码云上配置本地服务器的公钥

第一步：创建SSHKey。在用户主目录下，看看有没有 .ssh 目录，如果有，再看看这个目录下有没有 id_rsa 和 id_rsa.pu 这两个文件，如果已经有了

先执行 la 查看，发现有 .ssh 目录：

进入 .ssh，发现没有我们想要的两个文件

此时就需要配置一下， 返回上一级目录，执行 ssh-keygen -t rsa -C ".......@qq.com"
注意：这里的邮箱必须要与码云上的邮箱保持一致，执行后一路回车即可：

此时就将我们的公钥和私钥都创建好了，此时再进入 .ssh，就有了需要的这两个文件了：

下面 cat 打印 id_rsa.pub 公钥的内容，一字不少的粘贴进码云的 SSH公钥 设置的位置：

点击确定后，就会出现下面的页面，表示设置成功：

此时就会显示我们已经成功配置了一个 SSH 公钥了：
注意：如果我们是多人协作，也使用的 SSH 协议，这里也可以配置多个公钥，是支持配置多个公钥的

当我们配置完成后，继续复制 SSH 协议的链接，进入云服务器中进行克隆操作，现在就不会出现错误了：

此时就会多了一个基于 SSH 协议的远程仓库 remote-gitcode：

向远程仓库推送

想要将本地仓库中的修改推送到远程仓库中，下面梳理一下这个逻辑：

首先将工作区的修改使用 add 命令放入暂存区中，接着使用 commit 命令将暂存区的内容提交到本地仓库中的 master 分支，此时就相当于给 master 主分支上进行一次新的提交，对于本地仓库来说，它就有了一次新的修改了，这时远程仓库是看不到我们本地的修改的，如果想要看到，就需要进行一次推送 push 操作

push 操作就是把 master 分支上的修改  push 到远程仓库的 master 分支下，所以 push 操作是分支和分支之间的交互

下面先进入我们创建的 remote-gitcode 目录下，使用 git config -l 查看配置的相关信息，我们这里的 user.name 和 user.email 都需要和码云上的保持一致，所以下面进行相关配置：

执行 git branch，可以看到当前只有一个 master 分支，所以所有的改动都是在 master 分支上的

下面创建一个 file.txt 的文件，新增一行内容：

下面执行 add、commit 操作：

执行 git status 命令，查看状态，相比于之前，这次克隆的仓库多了框出来的内容：
建议我们使用 git push，将我们本地的提交进行一个推送操作

push 完整的命令如下：

• origin表示远程仓库的仓库名
• 第一个master表示本地仓库的分支名
• 第二个master表示远程仓库的分支名

如果本地和远程的分支名一样，就可以省略后一个分支名：

此时查看状态，就没有推荐 push 的提示了：

此时打开码云的 remote-gitcode 仓库，里面就有刚刚创建的 file.txt 文件：

file.txt 文件中存的内容就是我们本地添加的 hello git：

之所以可以 push 成功，是因为我们有 push 权限：

推送指的是远程分支和本地分支之间进行的交互，所以必须要让两个分支进行链接，成立一个关系，有这个关系才能成功的 push

对于远程仓库和本地仓库的 master 分支来说，在 git clone 的时候，git 会自动帮我们建立联系，所以直接 push 就能够成功

拉取远程仓库

push 操作是本地仓库的代码领先与远程仓库，为了让远程仓库保持最新的代码，我们必须要使用 push 操作，将本地仓库中最新的一些提交，推送至远程仓库中

下面需要介绍的是，远程仓库的内容领先于本地仓库的内容，这时需求就是：本地仓库需要看到远程仓库的代码

所以就需要进行 pull 拉取操作，将代码拉取到本地仓库中

之所以会出现上面这种情况，是因为上面我们给远程仓库推送了一个 file.txt 文件，其中有 hello git 内容，另一个同事此时克隆远程仓库，再新增一行内容 hello world，再 push 到远程仓库中，此时远程仓库的内容就领先于本地仓库了，也就是下面的情况：

我们想要让张三的本地仓库中，也有远程仓库新增的 hello world 代码，这种操作就是拉取操作

由于演示上面的场景需要两台服务器，而我们只有一台，所以我们直接在码云上修改(实际工作中不要在 master 分支上直接修改)

此时远程仓库中 file.txt 文件的内容就多了一行：

pull 完整的命令如下：

• origin表示远程仓库的仓库名
• 第一个master表示远程仓库的分支名
• 第二个master表示本地仓库的分支名

pull 其实做了两个工作：拉取 + 合并
将远程仓库的代码拉取到本地仓库中，再将本地仓库的代码和远程仓库的代码合并

同样的，如果本地仓库和远程仓库的分支名一样，也可以省略一个 master：

可以看到使用的是 ff模式，也就是进行了合并操作，此时查看 file.txt 文件，可以看到里面新增的内容：

查看当前的状态，是非常干净的，所以对于本地仓库来说没有任何的改动：

忽略特殊文件

下面介绍一个 Git 提供给我们的一个特殊的配置文件，即 .gitignore 文件，这个文件在我们第一次创建远程仓库时，初始化仓库的选项中就有一个 添加.gitignore：

下面详细说明这个文件的作用：

在日常开发中，我们有些文件不想或者不应该提交到远端，比如保存了数据库密码的配置文件，那怎么让 Git 知道呢
在 Git 工作区的根目录下创建一个特殊的 .gitignore 文件，然后把要忽略的文件名填进去，Git 就会自动忽略这些文件了

在我们创建仓库时，就可以勾选上这个文件，如果是 C++ 代码就选择 C++，其他语言也同样如此：

如果创建仓库的时候，没有选择，也可以在本地克隆的仓库中手动创建 .gitignore 文件：

表示所有以 so和ini 结尾的文件都忽略掉

下面我们创建一个 test.so 文件，再打印状态：

发现只显示一个 .gitignore 文件被 git 管理，没有 test.so 相关的提示

执行 add 操作后，再观察状态：

同样显示再暂存区中，只有一个 .gitignore 文件新增了，并没有 test.so 文件

下面再将另一个需求，如果我们有一个 example.so 文件，我们就是想让它进行一次提交，不想被忽略，有两种方式：

方式一：执行 git add -f example.so，-f 表示强制执行被忽略的文件
此时 example.so 文件就提交成功了

但是我们海狮建议尽量不要使用 -f 选项，因为 -f 选项是破坏 .gitignore 文件规则的

方式二：可以在 .gitignore 文件中手动指定不排除哪个文件：
在前面加一个感叹号表示不排除

也是能够满足这种需求的

如果有一天我们需要忽略的文件非常非常多，我们有创建一个 aaa.so 文件，我们想要查看这个 aaa.so 文件为什么被忽略，就可以执行 git check-ignore -v aaa.so：

就会显示在 .gitignore 文件的第二行，因为有 *.so，所以忽略了 aaa.so

下面将本地仓库的代码推送到远程仓库：

此时远端(码云)就能看到相关内容了：

配置命令别名

下面介绍一个特殊的 git 配置，例如我们前面查看当前仓库状态时，使用的是 git status，但是如果有些人觉得这个比较难写，想简便一点，例如使用 git st 查看仓库状态，这种也是被支持的，只不过需要特殊的配置

执行 git config --global alias.st status：

除了 git status，其余所有的选项都是可以配置的，例如我们前面所使用的打印出 git 提交的日志信息，想要好看一些，并且打印出缩写的 commit ID
需要执行 git log --pretty=oneline --abbrev-commit，比较长：

我们想简便一点，直接使用 git lpa 完成上述的效果，所以就执行：
git config --global alias.lpa 'log --pretty=oneline --abbrev-commit'

这种方式是非常方便的

Git的远程操作到此结束啦