【Git:远程操作和标签管理】从克隆到推送:Git 远程协作与标签管理实战指南

【Git:远程操作和标签管理】从克隆到推送:Git 远程协作与标签管理实战指南

🔥艾莉丝努力练剑:个人主页

专栏传送门:《C语言》《数据结构与算法》C/C++干货分享&学习过程记录Linux操作系统编程详解笔试/面试常见算法:从基础到进阶测试开发要点全知道

⭐️为天地立心,为生民立命,为往圣继绝学,为万世开太平


🎬艾莉丝的简介:


目录

艾莉丝的Gitee地址

1  ~>  远程操作

1.1  理解分布式版本控制系统

1.2  远程仓库

1.3  创建远程仓库

1.4  克隆远程仓库

1.4.1  使用HTTPS方式

1.4.2  使用SSH方式

1.5  向远程仓库推送

1.6  拉取远程仓库

2  ~>  配置Git

2.1  忽略特殊文件

2.2  配置命令别名

3  ~>  标签管理

3.1  标签在本地的一些操作

3.2  推送标签

3.3  删除标签

3.3.1  远程删除(不推荐)

3.3.2  本地删除(推荐)

Git:远程操作 / 标签管理部分博主手记

远程操作

标签管理

结尾


艾莉丝的Gitee地址

艾莉丝努力练剑的gitee


1  ~>  远程操作

1.1  理解分布式版本控制系统

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

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

分布式版本控制系统的安全性要高很多,因为每个人电脑里都有完整的版本库,某一个人的电脑坏掉了不要紧,随便从其他人那里复制一个就可以了。在实际使用分布式版本控制系统的时候,其实很少在两人之间的电脑上推送版本库的修改,因为可能你们俩不在一个局域网内,两台电脑互相访问不了。也可能今天你的同事病了,他的电脑压根没有开机。因此,分布式版本控制系统通常也有一台充当“中央服务器”的电脑,但这个服务器的作用仅仅是用来方便“交换”大家的修改,没有它大家也一样干活,只是交换修改不方便而已。有了这个“中央服务器”的电脑,这样就不怕本地出现什么故障了(比如运气差,硬盘坏了,上面的所有东西全部丢失,包括git的所有内容)

1.2  远程仓库

Git是分布式版本控制系统,同一个Git仓库,可以分布到不同的机器上。怎么分布呢?最早,肯定只有一台机器有一个原始版本库,此后,别的机器可以“克隆”这个原始版本库,而且每台机器的版本库其实都是一样的,并没有主次之分。

你肯定会想,至少需要两台机器才能玩远程库不是?但是我只有一台电脑,怎么玩?
其实一台电脑上也是可以克隆多个版本库的,只要不在同一个目录下。不过,现实生活中是不会有人这么傻的在一台电脑上搞几个远程库玩,因为一台电脑上搞几个远程库完全没有意义,而且硬盘挂了会导致所有库都挂掉,所以我也不告诉你在一台电脑上怎么克隆多个仓库。

实际情况往往是这样,找一台电脑充当服务器的角色,每天24小时开机,其他每个人都从这个“服务器”仓库克隆一份到自己的电脑上,并且各自把各自的提交推送到服务器仓库里,也从服务器仓库中拉取别人的提交。

完全可以自己搭建一台运行Git的服务器,不过现阶段,为了学Git先搭个服务器绝对是小题大作。好在这个世界上有个叫GitHub的神奇的网站,从名字就可以看出,这个网站就是提供Git仓库托管服务的,所以,只要注册一个GitHub账号,就可以免费获得Git远程仓库。

不过,github是国外的网站,速度比较慢,而且需要“科学上网”,我们统一采用码云来托管代码。接下来,我们从零开始,使用一下码云远程仓库。

1.3  创建远程仓库

我们注册一个码云账号,点击新建仓库,新建一个远程项目空间——

把基本的信息填写好——

像下面这样就是创建成功了——

创建成功后,我们可以对远程仓库进行一个基本的设置:开源或者私有,这个在仓库的【管理】那里可以修改,如下图所示——

从创建好的远程仓库中我们便能看到,之前在本地学习过的分支,也存在于远程仓库中并被管理起来了。刚创建的仓库有且只有一个默认的master分支——

1.4  克隆远程仓库

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

一般我们直接选HTTPS就行,SSH相对来说稳定一些,不过区别不大,克隆方式不一样。

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

1.4.1  使用HTTPS方式

hyb@139-159-150-152:~$ git clone https://gitee.com/hyb91/git_teaching.git Cloning into 'git_teaching'... Username for 'https://gitee.com': hyb91 Password for 'https://[email protected]': remote: Enumerating objects: 4, done. remote: Counting objects: 100% (4/4), done. remote: Compressing objects: 100% (4/4), done. remote: Total 4 (delta 0), reused 0 (delta 0), pack-reused 0 Unpacking objects: 100% (4/4), 1.80 KiB | 1.80 MiB/s, done. hyb@139-159-150-152:~$ ls gitcode git_teaching hyb@139-159-150-152:~$ ls git_teaching/ README.en.md README.md

1.4.2  使用SSH方式

我们直接来复制一下链接尝试一下——

hyb@139-159-150-152:~$ git clone [email protected]:hyb91/git_teaching.git Cloning into 'git_teaching'... The authenticity of host 'gitee.com (212.64.63.215)' can't be established. ECDSA key fingerprint is SHA256:FQGC9Kn/eye1W8icdBgrQp+KkGYoFgbVr17bmjey0Wc. Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added 'gitee.com,212.64.63.215' (ECDSA) to the list of known hosts. [email protected]: Permission denied (publickey). fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists.

把gitee对应的邮箱地址复制下来——

cat id_rsa.pub

把下面这一段公钥一个字符不少全部复制下来——

这里的标题可以随便给一个。

总结一下——

1.5  向远程仓库推送

本地已经clone成功远程仓库后,我们便可以向仓库中提交内容,例如新增一个file.txt文件:

# 新建⽂件 hyb@139-159-150-152:~/git_teaching$ ls README.en.md README.md hyb@139-159-150-152:~/git_teaching$ vim file.txt hyb@139-159-150-152:~/git_teaching$ cat file.txt hello git # 提交⽂件 hyb@139-159-150-152:~/git_teaching$ git add . hyb@139-159-150-152:~/git_teaching$ git commit -m"create file.txt" [master 7ce3183] create file.txt 1 file changed, 1 insertion(+) create mode 100644 file.txt

提交时要注意,如果我们之前设置过全局的name和e-mail,这两项配置需要和gitee上配置的用户
名和邮箱一致,否则会出错。或者从来没有设置过全局的name和e-mail,那么我们第一次提交时也会报错。这就需要我们重新配置下了,同样要注意需要和gitee上配置的用户名和邮箱一致。如何配置已讲过,在这里就不再赘述。

到这里,我们已经将内容提交至本地仓库中,如何将本地仓库的内容推送至远程仓库呢,需要使用git push命令,该命令用于将本地的分支版本上传到远程并合并,命令格式如下:

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

此时如果我们要将本地的master分支推送到origin主机的master分支,可以这样操作——

hyb@139-159-150-152:~/git_teaching$ git push origin master Enumerating objects: 4, done. Counting objects: 100% (4/4), done. Compressing objects: 100% (2/2), done. Writing objects: 100% (3/3), 308 bytes | 308.00 KiB/s, done. Total 3 (delta 0), reused 0 (delta 0) remote: Powered by GITEE.COM [GNK-6.4] To gitee.com:hyb91/git_teaching.git c6ce3f0..7ce3183 master -> master 

推送成功!这里由于我们使用的是SSH协议,是不用每一次推送都输入密码的,方便了我们的推送操作。如果你使用的是HTTPS协议,会有个比较麻烦的地方:每次推送都必须输入口令。

接下来,我们观察一下码云远端:

此时代码就已经被推送到远程仓库了——

1.6  拉取远程仓库

接下来,我们先在gitee上点击README.md文件,并在线修改它:

修改内容如下所示——

此时,远程仓库是要领先于本地仓库一个版本(在gitee上面可以在线修改,保存后远程仓库的代码就比本地仓库要新了),为了使本地仓库保持最新的版本,我们需要拉取下远端代码,并合并到本地。Git提供了git pull命令,该命令用于从远程获取代码并合并本地的版本。格式如下所示:

实践一下——

# 拉取远程分⽀,并与当前分⽀进⾏合并 hyb@139-159-150-152:~/git_teaching$ git pull origin master remote: Enumerating objects: 5, done. remote: Counting objects: 100% (5/5), done. remote: Compressing objects: 100% (3/3), done. remote: Total 3 (delta 1), reused 0 (delta 0), pack-reused 0 Unpacking objects: 100% (3/3), 1.02 KiB | 1.02 MiB/s, done. From gitee.com:hyb91/git_teaching * branch master -> FETCH_HEAD 7ce3183..60e6b0a master -> origin/master Updating 7ce3183..60e6b0a Fast-forward README.md | 2 ++ 1 file changed, 2 insertions(+) hyb@139-159-150-152:~/git_teaching$ cat README.md ... 第⼀次修改内容
远程仓库上面拉取到本地仓库;pull:拉取 + 合并

2  ~>  配置Git

2.1  忽略特殊文件

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

不需要从头写·gitignore文件,gitee在创建仓库时即可为我们生成,需要主动勾选:

在.gitignore文件中也可以指定(忽略或者不忽略)某个确定的文件。

最后一步就是把.gitignore也提交到远端,就完成了:

hyb@139-159-150-152:~/git_teaching$ vim .gitignore hyb@139-159-150-152:~/git_teaching$ git add . hyb@139-159-150-152:~/git_teaching$ git commit -m"add .gitignore" [master 97811ab] add .gitignore 1 file changed, 3 insertions(+) create mode 100644 .gitignore hyb@139-159-150-152:~/git_teaching$ git push origin master Enumerating objects: 4, done. Counting objects: 100% (4/4), done. Compressing objects: 100% (2/2), done. Writing objects: 100% (3/3), 362 bytes | 362.00 KiB/s, done. Total 3 (delta 0), reused 0 (delta 0) remote: Powered by GITEE.COM [GNK-6.4] To gitee.com:hyb91/git_teaching.git 60e6b0a..97811ab master -> master 

我们这就来验证一下.gitignore文件的能力,在工作区新增两个文件a.so和b.ini:

hyb@139-159-150-152:~/git_teaching$ touch a.so b.ini hyb@139-159-150-152:~/git_teaching$ git status On branch master Your branch is up to date with 'origin/master'. nothing to commit, working tree clean 

检验.gitignore的标准就是git status命令说“working tree clean”。我们发现Git并没有提示在工作区中有文件新增,果然.gitignore生效了!

但有些时候,你就是想添加一个文件到Git,但由于这个文件被.gitignore忽略了,根本添加不了,那么可以用-f选项强制添加:

$ git add -f [filename]

或者如果你发现,可能是.gitignore写得有问题,需要找出来到底哪个规则写错了——比如说a.so文件是要被添加的,可以用git check-ignore命令检查:

hyb@139-159-150-152:~/git_teaching$ git check-ignore -v a.so .gitignore:3:*.so a.so

Git会告诉我们,.gitignore的第3行规则忽略了该文件,于是我们就可以知道应该修订哪个规则。还有些时候,当我们编写了规则排除了部分文件时,例如:

# 排除所有.开头的隐藏⽂件: .*

但是我们发现.*这个规则把.gitignore也排除了。虽然可以用git add -f强制添加进去,但有强迫症的uu还是希望不要破坏.gitignore规则——这个时候,可以添加一条例外规则:

# 排除所有.开头的隐藏⽂件: .* # 不排除.gitignore !.gitignore

把指定文件排除在.gitignore规则外的写法就是! + 文件名,所以,只需把例外文件添加进去即可。

2.2  配置命令别名

在我们使用Git期间,有些命令敲的时候着实让人头疼(命令实在是太长了!!!),幸运的是:git支持对命令进行简化!其实和C / C++的typedef道理类似,本质上更加接近于引用。

举个例子,将git status简化为git st,对应的命令为:

$ git config --global alias.st status

--global参数是全局参数,之前也见过了,--global的意思就是这些命令在这台电脑的所有Git仓库下都有用;如果不加,就只会对当前的仓库才起作用。

好了,现在我们来试着敲一下git st看看效果:

hyb@139-159-150-152:~/git_teaching$ git st On branch master Your branch is up to date with 'origin/master'. nothing to commit, working tree clean

再来配置一个git last,让其显示最后一次提交信息:

$ git config --global alias.last 'log -1'

如此,用git last就能显示最近一次的提交:

hyb@139-159-150-152:~/git_teaching$ git last commit 97811abd1d43774aeb54fee32bf4fc76b2b08170 (HEAD -> master, origin/master, origin/HEAD) Author: hyb91 <[email protected]> Date: Fri May 12 17:27:06 2023 +0800 add .gitignore

但是,目前不建议大家使用,等到大家工作了再去使用起来简化工作吧!现在我们还在学习的阶段,所有的命令都要手动完成,尽快适应Git。


3  ~>  标签管理

3.1  标签在本地的一些操作

标签(tag):对某次commit的一个标识(别名)。

版本回退时通过标识可直接找到(很快定位到)对应的commit id。

git tag v1.0

默认给最新一次的提交打标签。

如何看待标签?

git tag

这个命令会列举出当前有哪些标签,或者也可以这样——

tree .git
cat .git/refs/tags/v1.0

再git log一下,查看是不是给最新一次提交打标签

git log --pretty=online --abbrev-commit

先用上面这个命令查看一下日志,如下所示——

我们把要打标签那次提交的commit id复制一下——

git tag v0.9 [commit id]

再git tag一下——

注意这里不是按(创建标签的)时间排序的,而是按英文单词排序的。

3.2  推送标签

远程仓库中标签也有一些功能。

先git tag查看一下当前有哪些分支——

一次推送一个标签(后面直接跟标签名)——

一次推送所有的标签——

如下图所示,推送成功——

3.3  删除标签

3.3.1  远程删除(不推荐)

直接在远程仓库就可以删除了——不推荐远程删除——

3.3.2  本地删除(推荐)

本地删除,并且将修改提交到远程仓库。


Git:远程操作 / 标签管理部分博主手记

远程操作

标签管理


结尾

创作过程中难免有所缺漏,如果uu们发现艾莉丝的文章哪里有所疏忽,望不吝赐教!感谢支持!

往期回顾:

【Git:分支管理】Git 分支管理完全指南:从创建、合并到冲突解决

结语:都看到这里啦!那请大佬不要忘记给博主来个“一键四连”哦! 

🗡博主在这里放了一只小狗,大家看完了摸摸小狗放松一下吧!🗡

૮₍ ˶ ˊ ᴥ ˋ˶₎ა


Read more

OpenClaw gateway start 报 401 Invalid API key?一个环境变量的坑

今天折腾了半小时,终于搞明白为什么 openclaw gateway start 一直报 HTTP 401: Invalid API key,而 openclaw gateway run 却能正常工作。 记录一下,免得以后又踩。 问题现象 用 openclaw gateway run 前台运行,一切正常,能正常对话。 但换成 openclaw gateway start(systemd 后台服务),就报错: HTTP 401: Invalid API key 明明配置文件里 API key 写得好好的,为什么会这样? 原因分析 run 和 start 的区别: * run — 前台运行,

By Ne0inhk
零基础手把手教你完成一个毕设(四):需求到架构——画出专业级系统图的实战方法

零基础手把手教你完成一个毕设(四):需求到架构——画出专业级系统图的实战方法

这是“零基础教你完成一个毕设”系列的第四篇。前三篇我们讲了选题、文档、项目落地。今天,我们要进入毕设中最关键、最“硬核”的部分——系统架构设计。 很多同学写论文时最头疼的部分,就是那张“系统总体架构图”或“系统功能结构图”。一看到论文模板里的那一栏,脑袋就嗡地一声:“这图要怎么画?” 别急,今天我就带你从需求一步步推导出系统架构,并教你如何画出既专业又好看的系统图。 一、为什么要做系统架构设计? 我们先搞清楚一个问题:为什么老师、评审、企业都这么看重系统架构? 系统架构就像是一栋楼的蓝图。 如果说需求分析是“要盖什么楼”,那系统架构就是“楼要怎么盖、用什么材料、分几层、谁负责哪一部分”。 有了架构,才能指导后续编码、测试、部署。如果架构没设计好,项目做到一半就容易崩盘——模块互相打架、逻辑混乱、维护困难。 一个好的架构图,应该能回答三个问题: 1. 系统解决了什么问题?

By Ne0inhk
OpenClaw 多智能体架构配置,给你讲得明明白白!

OpenClaw 多智能体架构配置,给你讲得明明白白!

手把手教你一键部署OpenClaw,连接微信、QQ、飞书、钉钉等,1分钟全搞定! 一)第一步:把当前账号设为老大(main) 如果你现在手头只有一个机器人,得先给它个“总管”的身份。 1. 先查查底子 openclaw status # 正常应该看到:Agents: 1 (main) # 要是没看到 main,就按下面走 2. 跟 AI 提需求(怎么说都行,意思对就行) 我想搞多机器人架构,现在这一个帮我设成主账号(main),辛苦帮我配一下。 3. 点头确认 确认 手把手教你一键部署OpenClaw,连接微信、QQ、飞书、钉钉等,1分钟全搞定! 4. 搞定 ✅ 主账号已就位 二)第二步:招募新“

By Ne0inhk
FastAPI架构深度解析:依赖注入、后台任务与WebSocket实战

FastAPI架构深度解析:依赖注入、后台任务与WebSocket实战

目录 1. 🎯 FastAPI为何脱颖而出? 2. 🏗️ 架构设计:异步优先 2.1 真正的异步支持 3. 🔧 依赖注入:FastAPI的灵魂 3.1 依赖注入三层架构 3.2 实战:企业级依赖系统 4. ⚡ 后台任务系统 4.1 BackgroundTasks vs Celery选择 4.2 实战:BackgroundTasks高级用法 5. 🌐 WebSocket实时通信 5.1 WebSocket架构设计 5.2 实战:聊天系统实现 6. 🛡️ 中间件与安全 6.1 中间件执行流程 6.2 实战:安全中间件 7. 📊 性能监控与优化

By Ne0inhk