【Git版本控制器--3】Git的远程操作

目录

理解分布式版本控制系统

创建远程仓库 

仓库被创建后的配置信息 

克隆远程仓库 

https克隆仓库 

ssh克隆仓库 

向远程仓库推送

拉取远程仓库 

忽略特殊文件 

为什么要忽略特殊文件？ 

如何配置忽略特殊文件？ 

配置命令别名

标签管理

理解标签 

标签操作

---

理解分布式版本控制系统

为什么要有分布式版本控制系统？

在之前的文章中，我们已经对Git的使用有了一个认知，但我们之前的git操作全部都是对本地仓库的管理，不管是分支管理还是基本操作...

本地仓库是保存在一台服务器中的。这意味着，假设你需要与你的同事一块进行多人开发，那么你和你的同事需要围在一台电脑上进行开发，那么这样子的开发不仅仅不会提高开发效率，甚至在某些情况下会降低开发效率！

所以我们需要有方式能够让你和你的同事在不同的电脑上拿到同一个仓库的内容，而在git中，分布式版本控制系统完美做到了！

---

什么是分布式版本控制系统？

在还没有分布式版本控制系统时，你需要与你的同事进行多人开发，那么其实也有方案：

你可以把你的本地仓库，原封不动的拷贝给你的同事，你的同事也可以把他的本地仓库原封不动的拷贝给你！这样就实现了不同主机之间可以拿到同一个仓库！

这种方案与本地仓库相比带来了好处：当你的本地仓库因为某些突发情况丢失时，你的同事那还有备份，提高了安全性！

但这种方案也有着一些问题：

• 直接进行拷贝相对比较麻烦
• 当你的同事因为某些原因，例如：生病了，离职了...时，你无法拿到你同事的本地仓库。这就带来了局限性

基于上述原因，我们不考虑这种将本地仓库直接拷贝的方案

第二种解决方案：

创建一个中央服务器。中央服务器的仓库中保存着项目的内容。中央服务器把你和你同事的电脑进行连接，这意味着你和你的同事可以在自己的计算机上对中央服务器仓库中的内容进行克隆。这样，你们能拿到同一个仓库！

当你对仓库的内容进行了修改时，你把你的修改完的仓库内容上传到中央服务器中，这个动作我们称之为推送！

当你需要拿到你同事的修改内容时，直接把中央服务器中你同事的仓库内容拿到本地，这个动作我们称之为拉取！

这种方案解决了第一种方案所产生的各种问题！这一套体系是集中式版本控制系统，即包含图中所有电脑的本地仓库与中央服务器仓库构成的一套系统！而git所提供的分布式版本控制系统的基础就是集中式版本控制系统，它包含了集中式版本控制系统的所有优点，但提供了比起这种方案更强大、更灵活的多人协作开发功能！

若我们维护一个仓库时，还需要手动架构一台中央服务器，那么成本是巨大的！

所以很多网站为我们提供了中央服务器的功能，例如github、码云...(后续用码云)

我们可以把自己的本地仓库推送到这些网站中，别人也能从这些网站中拉取我们的仓库，实现了多人协作的功能！所以这些网站充当的相当于中央服务器的角色

---

创建远程仓库 

当我们注册并登录上码云后，如下步骤：

 

 

仓库名称是必填项，并且仓库名称尽量与它的内容相对应！

---

仓库被创建后的配置信息 

---

ReadMe文件模板

ReadMe文件模板：当勾选该选项时，创建仓库后会自动生成一个ReadMe文件，ReadMe文件用于对该仓库的说明。自动生成的ReadMe文件有中英文两个版本

实际上，ReadMe文件就相当于一个使用说明书一样的东西！

---

成员管理 

仓库成员管理：在仓库页面的右上方可以对仓库的成员进行管理！说明一个仓库是能进行多人开发的

 如下为git手册中对成员身份的描述：

---

Issue文件

通过git对成员身份的描述可以发现，每一个成员都能创建一个名为Issue的东西

实际上Issue就是对该仓库中的某个事件进行描述的，比如说bug之类的！每一个人都能提交自己的Issue，并通知仓库管理员来解决

若在创建仓库时勾选了Issue模板文件，则新建Issue时如下：

新增Issue时有一些配置选项：

• 负责人：该问题你需要通知谁来解决！
• 标签：该Issue描述的是什么事件，可以填例如bug，duplicate...
• 分支：你描述的问题是在哪个分支下发现的
• .....

如下为创建好一个Issue时的样子：

当该问题被解决时，记得对Issue设置为已完成状态

---

Pull Request文件 

我们都知道，当一个分支的内容写完了，那么它需要合并到master分支上。

但不是什么内容都能被合并到master分支上的，假设你的代码中存在了很多bug，合并到master分支上，导致线上运行环境崩溃，那么就gg了。

但不是每一个开发人员都了解这些的，所以需要有硬性要求约束开发人员。

所以在合并之前，你需要询问仓库的管理员是否可以合并，若管理员同意，那么你才能进行合并操作！ 

如何询问？提交一份Pull Request请求给管理员！

若在创建仓库时勾选了Pull Request文件模板，那么会在仓库中生成如下文件

这份文件是给开发人员看的，要求开发人员在提交Pull Request时的格式

如何提交一份Pull Request？

---

克隆远程仓库 

克隆远程仓库的协议有两个

• https协议
• SSH协议 

区别：

• SSH克隆：使用SSH（Secure Shell）协议进行克隆，该协议通过加密技术保护数据传输过程中的机密性和完整性，防止数据被窃取或篡改。同时，SSH协议使用公钥加密技术进行身份验证，进一步增强了安全性，可以防止密码被盗取或猜测。
• HTTP克隆：通过HTTP或HTTPS协议进行克隆，虽然HTTPS也提供了加密通信，但在身份验证方面相对较弱，通常依赖于用户名和密码进行验证，这可能存在被暴力破解或泄露的风险。
• 总而言之SSH克隆比起https克隆更加安全

---

https克隆仓库 

复制完https的地址时，可以使用如下指令在Linux中克隆一份仓库： 

git clone [远程仓库地址(https)]

 注意：不要在本地仓库下直接进行clone操作，因为clone也会生成一份.git版本库，直接克隆会导致本地仓库下的.git被覆盖！

此时本地和远程仓库之间的结构图如下：

clone完以后会在本地生成一个对应的本地仓库！

origin表示远程仓库默认名称

查看远程仓库名称：（必须在仓库的工作区下）

git remote

查看更详细的信息可以使用-v选项 

使用-v选项会出现两个地址，与其相对应的权限

图上的内容为，我既有对远程仓库的拉取权限又有远程仓库的推送权限 

---

ssh克隆仓库 

SSH协议使用公钥加密技术进行身份验证。在配置SSH克隆时，用户需要在本地生成SSH密钥对，并将公钥添加到Git托管服务上。这样，在克隆仓库时，Git托管服务会使用公钥来验证用户的身份，确保只有授权的用户才能访问和克隆仓库。

---

如何配置公钥

第一步： 

第二步： 

第三步：填写公钥信息即可完成公钥的配置

标题：可以按照自己喜欢的设置

接下来的重点是获取我们本地服务器的公钥

---

获取本地服务器的公钥 

第⼀步：创建SSH Key。在用户主⽬录下，看看有没有.ssh⽬录，如果有，再看看这个⽬录下有没有 id_rsa 和 id_rsa.pub 这两个⽂件，如果已经有了，可直接跳到下⼀步。如果没有，需要创建 SSH Key： 

创建SSH Key：

ssh-keygen -t rsa -C "[邮箱]" 

输入完上述指令后一路回车即可！ 

 注意：邮箱必须与我们在码云上配置的邮箱相同

经过配置之后，我们的家目录下就有了ssh文件，里面保存着公钥(id_rsa)和私钥(id_rsa.pub)

第二步：查看id_rsa.pub内容，并把查看到的内容复制到码云的公钥配置项上

弹出如下页面表示配置成功

---

ssh克隆仓库 

配置好公钥以后，我们就可以使用ssh的方式进行克隆了。流程几乎与https一样，如下步骤：

第一步：

第二步：

第三步：在Linux下输入如下指令

git clone [复制的内容]

---

向远程仓库推送

向远程仓库推送的整个过程：

• 在工作区中对代码完成修改
• 通过add操作把修改内容添加到暂存区
• 通过commit操作把修改内容添加到master分支
• 把master分支修改内容推送到远程仓库，即push操作

根据图中我们可以看出，实际上push操作是分支与分支之间的交互，即本地仓库中的master分支推送到远程仓库中的master分支，这两个分支不是同一个分支！ 

push操作对应指令：

git push [远程仓库名] [本地分支名]:[远程分支名]

若本地分支名与远程分支名一致，那么可以把远程分支名进行省略 

注意：若采用的是ssh的方式进行push操作，那么无需输入用户名和密码，若是https的方式则需要输入用户名和密码！

 

---

拉取远程仓库 

 什么场景下需要拉取远程仓库？

假设你和你的同事一起开发了一个产品，并推送到了远程仓库中，此时你的仓库、你同事的仓库、远程仓库中该产品的版本都是version0版

突然某一天，你的同事开发了一个新的功能，此时你的同事的产品版本更新成了version1版，它把它的version1版的代码推送到了远程仓库中，远程仓库中产品的版本也变为了version1版，但你的仓库里面的版本是version0版，若你也需要拿到这个version1版，你就需要拉取远程仓库中的version1版本的代码！ 

---

如何拉取？

拉取远程仓库中的内容：

git pull [远程仓库名] [本地分支名]:[远程分支名]

注意：pull不仅仅是拉取了远程仓库中的内容，而且还把拉取得内容与本地分支进行合并！

与push一样，若我们的本地分支名和远程分支名一样，那么远程分支名可以省略！

---

案例演示 

为了方便演示，我使用码云平台提供的代码编辑功能手动更新代码，如下方法：

修改后：

注意：实际开发中，不要手动编辑代码！

之后远程仓库中的代码被修改，我们在Linux中使用pull操作拉取远程仓库的内容

---

忽略特殊文件 

为什么要忽略特殊文件？ 

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

有人可能会说，假设是不想让配置文件进行提交，那么我们在add的时候不添加这些配置文件不就可以了吗？

实际上，这种方法硬要说的话也行！但在我们实际开发中，我们一般一次开发修改的是十几个文件，你难道要一个一个add吗？我们常用的方式是git add . 把当前目录所有修改内容都add。但若你add时恰好有一个配置文件被修改了，那不就上传到git了吗？

---

如何配置忽略特殊文件？ 

在我们创建的时候有一个.gitignore模板，我们如果勾选了的话直接修改里面的内容就可以了！

但若我们没有勾选也没关系，我们直接在工作区创建一个.gitignore即可

接下来的问题是，.gitignore中的内容我们如何设置呢？

---

忽略某个特殊文件 

假设我们想忽略某一个特殊文件，我们直接直接在.gitignore中把该文件的文件名添加到.gitignore中

 

上图中，由于file.abc被ignore了，我们无法添加该文件

---

忽略某一类特殊文件 

除了忽略某一个特殊文件以外，我们还可以忽略一类文件，例如.efg结尾的文件，把*.efg添加到.gitignore中即可

我们在日常开发中，肯定不会这样指定一个被忽略的文件，一般都是被忽略的文件和要上传的文件放到一起，那么此时git不会提示，而是自动把被忽略的文件不放到暂存区，未被忽略的文件放到暂存区中 

 可以看到，只有file.txt被推送到了远程仓库中，而file.abc和file.efg都被忽略了

---

不忽略某个特殊文件 

注意：若我们想要强制添加被忽略的文件，可以在add时带上-f选项即可，

当然，若是add时带上-f选项，显然破坏了.gitignore的忽略规则，所以一般不建议这样使用，我们若只是想add一个特殊的文件，假设这个特殊的文件是test.abc，那么把!test.abc添加进.gitignore，此时就不会忽略这一个文件！

可以看到test.abc被成功添加到了暂存区中！ 

---

.gitignore文件内容非常多，查看被忽略原因所在的行数

接下来的场景是假设你的.gitignore中的内容已经非常多了，你不知道具体忽略了哪些文件，git提供了方法可以让你查看到该文件被忽略原因在.gitignore中的第几行

查看被忽略的原因所在的地方：

git check-ignore -v [文件名]

 

 如图中，查看到file.efg被忽略原因是因为.gitignore中有一行是*.efg，行数是第二行，文件是.gitignore

---

配置命令别名

在我们实际开发中，可能有的git命令非常长，导致我们每次输入时的不方便，我们可以使用如下方法对git命令进行取别名

 配置全局命令别名：

git config --global alias.[新名字] '[老名字]'

例如：

有些时候，我们设置了命令别名可能自己也忘记了，可以通过如下方法查看所有的命令别名

查看配置的全局命令别名： 

git config --global --get-regexp alias

 例如：

若我们不想使用命令别名了，可以使用如下方法删除命令别名 

删除全局某个命令别名：

git config --global --unset alias.[命令别名]

例如：

 删除全局所有命令别名：

git config --unset-all

---

标签管理

理解标签 

什么是标签？

 git中，标签是用来标识某些特殊提交的一种记号，比如产品上线时的提交，一般都需要打上标签

---

为什么要有标签 

git中不是每一次提交的时候都有commit id吗？commit id能唯一标识一次提交，为什么还需要标签呢？

commit id vs 标签：

• commit id：通过哈希算法得出来的，本身比较长，难以记忆！并且commit id都是无意义的一串字符
• 标签：通过开发人员手动打上的标签，通常都要保证尽量简短且与提交内容有强关联！标签被设置出来就是有意义的，方便开发人员查看！
• commit id 每一次提交都有，当提交过多时会导致难以查看。而只有当重要提交上传时才会打上标签，所以实际开发中打上标签的提交不会非常多，容易查看！

所以标签是针对重要的提交，我们可以为该提交打上标签，方便管理

例如：产品上线时的提交可以打上v1.0的标签，表示版本号！

对于开发人员来说，被打上标签的提交通常都是具有里程碑意义的！并且当开放人员想进行重要版本的回退时，可以根据标签迅速完成版本回退，提升了开发效率！

---

标签操作

---

本地操作 

添加标签：

git tag [标签名]

上述命令的默认行为是为我们最近一次提交打上标签

查看有哪些标签：

git tag

注意：添加标签后，会在.git/refs/tags目录下保存了名字与标签名相同的文件，这个文件的内容是commit id

示例：  

为非最新的提交打上标签：

git tag [标签名] [commit id]

有些时候，我们可能不仅仅需要添加标签，还需要添加对该标签的描述信息，可以使用如下方法：

标签描述：

git tag -a [标签名] -m"[标签描述]" [commit id]

 若不写commit id的话，默认是最近一次提交！

查看标签描述：

git show [标签名]

删除标签：

git tag -d [标签名]

示例：

---

远端操作 

 

标签也可以推送给远端仓库

推送一个标签：

git push [远程仓库名] [标签名]

推送所有标签：

git push origin --tags

若我们不需要远程仓库中的某一个标签，不建议直接在码云上手动删除，最好是先在本地删除，再把本地仓库与远程仓库进行同步：

 本地删除后与远程仓库的同步：

git push [远程仓库名] :[标签]
#本质是把本地的删除同步到远端