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内容都已经讲解完毕,如果有不懂或者疑问的地方,欢迎评论区提问~

相关推荐
大猫和小黄2 小时前
Windows、CentOS环境下搭建自己的版本管理资料库:GitBlit
linux·服务器·windows·git
孤水寒月2 小时前
Git忽略文件.gitignore
git·elasticsearch
DN金猿10 小时前
git命令恢复/还原某个文件、删除远程仓库中的文件
git
DWei_GaGa13 小时前
Git:查看分支、创建分支、合并分支
git
涵信15 小时前
Windows11 安装 Ubuntu-20.04,同时安装配置 zsh shell,配置 git 别名(alias),大大提高开发效率
linux·git·ubuntu·bash
喝鸡汤18 小时前
一起学Git【第五节:git版本回退】
git
web Rookie19 小时前
Git的简介
git
苏三有春1 天前
五分钟学会如何在GitHub上自动化部署个人博客(hugo框架 + stack主题)
git·go·github
high20111 天前
【Git】-- 版本说明
git
kaixin_learn_qt_ing1 天前
git clone
git