云托管是什么

简介: 系列

【摘要】这次体验主要是使用基于Git,布局于华为DevOps工具链的代码托管服务来创建仓库,目的体验其具备安全管控,成员、权限管理,分支保护/合并,统计服务等功能的云端代码仓库。既然CodeHub是基于Github的在线托管服务,一是熟悉Git操作命令,二是重点介绍云代码托管服务带来的方便。

这次体验主要是亲自创建云代码仓库,并进行合理的协同开发,还有端到端可追溯,这个功能在企业项目管理,研发DevOps中发挥重要作用,从代码变更到软件的部署,这样全流程是可以追溯的。最后是介绍服务的重要特点以及实际体验的思考。

开胃菜-熟悉Git

首先基础知识是Git这种分布式控制系统要理解清楚,分布式的意思是没有中央服务器的,每个人的电脑就是一个完整的版本库,这样,工作的时候就不需要联网了,因为版本都是在自己的电脑存起来的。既然每个人的电脑都有一个完整的版本库,那多个人如何协作呢?比如说自己在电脑上改了文件A,其他人也在电脑上改了文件A,这时,你们两之间只需把各自的修改推送给对方,就可以互相看到对方的修改了。

常见的名词

版本: 版本管理器当然要有版本, V1.0.0, V1.0.1 等等, 每个版本都有自己独一无二的名字, 是一个 40 位长的 hash 值;

分支: 分支 branch 就是把一系列版本串在一起的东西. 一条分支上有多个(或者 1 个)版本, 主分支叫做 master, 同样也是默认分支, 代表着版本的开发历程; 一条分支就是一些版本的集合.

HEAD: 是一个指针, 代表着 git 正在使用的版本(不是分支), git 每一次只能看向一个版本;

远程仓库: git 不只是 仅仅在本地, 或者 仅仅在远程 使用. 仓库远程 origin 是大家一起做好的版本存放的地方.

Git 的结构

git 在进行版本控制是通过 4 个部分来实现的: 工作区, 暂存区, 仓库, 远程仓库;

Workspace:工作区
就是能在电脑里能看到的目录,比如 c:/Code 文件夹就是一个工作区, 每一个git的工作区都是有一个.git文件夹, 里面保存着版本信息:

Index / Stage:暂存区
用于存放刚刚经过修改并且没有经行上传的版本, 也是在本地的. 通过 git add . 来把所有工作区内所有文件添加到暂存区

Repository:仓库区(或本地仓库 / 版本库)
在工作区, 例如c:/Code有一个隐藏目录.git 这个不是工作区, 而是工作区的版本库 (Repository). 通过git commit -m "message"来提交版本;

Remote:远程仓库
是运程存放代码的地方, 相当于你工作区的备份 ,例如 github, gitlab. 通过git push提交到远程仓库

基本用法

下面的四条命令在工作目录、暂存目录(也叫做索引)和仓库之间复制文件,你看下图来理解。

  • git add files 把当前文件放入暂存区域。
  • git commit 给暂存区域生成快照并提交。
  • git reset -- files 用来撤销最后一次git add files,你也可以用git reset 撤销所有暂存区域文件。
  • git checkout -- files 把文件从暂存区域复制到工作目录,用来丢弃本地修改。


你可以用 git reset -p, git checkout -p, or git add -p进入交互模式。

也可以跳过暂存区域直接从仓库取出文件或者直接提交代码。

  • git commit -a 相当于运行 git add 把所有当前目录下的文件加入暂存区域再运行。git commit.
  • git commit files 进行一次包含最后一次提交加上工作目录中文件快照的提交。并且文件被添加到暂存区域。
  • git checkout HEAD -- files 回滚到复制最后一次提交。

约定

后文中以下面的形式使用图片。

绿色的5位字符表示提交的ID,分别指向父节点。分支用橘色显示,分别指向特定的提交。当前分支由附在其上的HEAD标识。 这张图片里显示最后5次提交,ed489是最新提交。 master分支指向此次提交,另一个maint分支指向祖父提交节点。

图解常见的命令

Diff

有许多种方法查看两次提交之间的变动。下面是一些示例。

Commit

提交时,git用暂存区域的文件创建一个新的提交,并把此时的节点设为父节点。然后把当前分支指向新的提交节点。下图中,当前分支是master。 在运行命令之前,master指向ed489,提交后,master指向新的节点f0cec并以ed489作为父节点。

即便当前分支是某次提交的祖父节点,git会同样操作。下图中,在master分支的祖父节点maint分支进行一次提交,生成了1800b。 这样,maint分支就不再是master分支的祖父节点。此时合并(或者衍合) 是必须的。

如果想更改一次提交,使用 git commit --amend。git会使用与当前提交相同的父节点进行一次新提交,旧的提交会被取消。

另一个例子是分离HEAD提交,后文讲。

Checkout

checkout命令用于从历史提交(或者暂存区域)中拷贝文件到工作目录,也可用于切换分支。

当给定某个文件名(或者打开-p选项,或者文件名和-p选项同时打开)时,git会从指定的提交中拷贝文件到暂存区域和工作目录。比如,git checkout HEAD~ foo.c会将提交节点HEAD~(即当前提交节点的父节点)中的foo.c复制到工作目录并且加到暂存区域中。(如果命令中没有指定提交节点,则会从暂存区域中拷贝内容。)注意当前分支不会发生变化。

当不指定文件名,而是给出一个(本地)分支时,那么HEAD标识会移动到那个分支(也就是说,我们"切换"到那个分支了),然后暂存区域和工作目录中的内容会和HEAD对应的提交节点一致。新提交节点(下图中的a47c3)中的所有文件都会被复制(到暂存区域和工作目录中);只存在于老的提交节点(ed489)中的文件会被删除;不属于上述两者的文件会被忽略,不受影响。

如果既没有指定文件名,也没有指定分支名,而是一个标签、远程分支、SHA-1值或者是像master~3类似的东西,就得到一个匿名分支,称作detached HEAD(被分离的HEAD标识)。这样可以很方便地在历史版本之间互相切换。比如说你想要编译1.6.6.1版本的git,你可以运行git checkout v1.6.6.1(这是一个标签,而非分支名),编译,安装,然后切换回另一个分支,比如说git checkout master。然而,当提交操作涉及到"分离的HEAD"时,其行为会略有不同,详情见在下面。

HEAD标识处于分离状态的提交操作

当HEAD处于分离状态(不依附于任一分支)时,提交操作可以正常进行,但是不会更新任何已命名的分支。(你可以认为这是在更新一个匿名分支。)

一旦此后你切换到别的分支,比如说master,那么这个提交节点(可能)再也不会被引用到,然后就会被丢弃掉了。注意这个命令之后就不会有东西引用2eecb。

但是,如果你想保存这个状态,可以用命令git checkout -b name来创建一个新的分支。

 和集中式版本控制系统相比,分布式版本控制系统的安全性要高很多,因为每个人电脑里都有完整的版本库,某一个人的电脑坏掉了不要紧,随便从其他人那里复制一个就可以了。而集中式版本控制系统的中央服务器要是出了问题,所有人都没法干活了。

  在实际使用分布式版本控制系统的时候,其实很少在两人之间的电脑上推送版本库的修改,因为可能你们俩不在一个局域网内,两台电脑互相访问不了,也可能今天你的同事病了,他的电脑压根没有开机。因此,分布式版本控制系统通常也有一台充当“中央服务器”的电脑,但这个服务器的作用仅仅是用来方便“交换”大家的修改,没有它大家也一样干活,只是交换修改不方便而已。

  当然,Git的优势不单是不必联网这么简单,后面我们还会看到Git极其强大的分支管理,把SVN等远远抛在了后面。

  CVS作为最早的开源而且免费的集中式版本控制系统,直到现在还有不少人在用。由于CVS自身设计的问题,会造成提交文件不完整,版本库莫名其妙损坏的情况。同样是开源而且免费的SVN修正了CVS的一些稳定性问题,是目前用得最多的集中式版本库控制系统。

  除了免费的外,还有收费的集中式版本控制系统,比如IBM的ClearCase(以前是Rational公司的,被IBM收购了),特点是安装比Windows还大,运行比蜗牛还慢,能用ClearCase的一般是世界500强,他们有个共同的特点是财大气粗,或者人傻钱多。

云代码仓库服务

现在咱们知道了分布式版本控制系统的基础,包括涉及到的名词,git它的流程结构是咋样,还包括它的各个命令的原理是什么,最后是分布式版本系统给我们代码托管带来的好处有哪些,这些都是学习华为云代码托管服务重要的前提知识点。接着咱们开始创建一个云代码仓库,完整体验各个功能。

先到官网定位到开发-运维,选择点击代码托管CodeHub

进入到控制台选代码托管

如果你是小白点快速开始,这样整个流程会比较简单的,像咱们点击后面蓝色的普通创建,如果想把你gihub的仓库导入也行哈

后面进入普通创建,选择填写项目名称,仓库名称以及描述,系统会自动勾选代码检索服务,然后你要选择要不要配置.gitignore,还有要不要开源这些看你

创建成功后是下图这样,后面点击有四个选项,咱们选择仓库设置。

看看这个和咱们天天在用的github到底有什么不同的地方,还别说,有IP白名单,异地备份和风险操作,提交网络这些github都是没有的功能。

咱们在回退到项目设置里面去,这个功能有权限管理,服务菜单管理,服务扩展点管理和主机组管理;我相信你能从字面上理解它,我就我重新介绍了哈。

咱们再前进到仓库设置,不知道你有没有看见锁定仓库的设置,目的防止任何人破坏即将发布版本的代码仓库,管理员可以锁定仓库。
在锁定仓库后,任何人都无法向任何分支提交代码(包括管理员本人)。一般情况下千万不要乱动吧。

回到仓库文件这里能够对其中自己的文件进行在线的查看,编辑还能回退以及删除。

并且你能够向仓库新建文件目录,新建子模式以及重要的上传文件,这些如果是在github是不能够做到的,这点很细节。

现在我们在master分支下创建test.java后,我们能够对历史查看,然后修改追溯,以及对代码进行对比,这些一般在git命令进行操作是吧

然后我们在仓库创建分支,进行合并请求,意思是选择两个分支以查看更改或开始新的请求。只有两个分支的内容有差异的情况下才允许合并。


注意你目标分支,这里很合理的可以选择合并人和评审人对这样的项目管理是很方便,还有你可以具体关联某个工作项。

你如果还不清楚的代码的业务流程,你可以看代码的评审记录,包括的你提交和合并请求两个部分。

我们来看下关联工作项这是在企业开发中很实用的功能,方法为用户需在提交代码时,录入工作项编号,来实现工作项与代码的双向关联。提交代码时录入信息的格式为“fix #工作项编号 本次提交的注释信息”。

如果你的代码在你的开发组已经开发完毕,现在可以选择文件的新建编译构建任务。

当然构建不是那么简单,需要工具构建,然后设置命令,setting配置发布依赖包最后是单元测试,这些在常用的Github也是没有的。

我们还是在仓库里面的除了代码托管,还有特有的代码检查的功能,设置有质量门禁,检查时间,以及产生新的问题这些实用的功能。

如果是问题的可以设置锅炉器,针对问题级别,状态或者时间其他的手段来进行过滤。

然后还有一个很重要的就是仓库统计,你能够查看总的提交次数,提交频率,以及提交人数以及时间,对于项目维护者来说很实用的。

那么对于仓库来说,可以做非常详细的介绍,比如初始图,先用了多少容量,有多少分支数,上次统计时间等来显示。

最后就是设置中的异地备份这个是在一些紧急情况下非常重要的选择,你可以吧自己的项目备份到其他地区的云服务器,这样保证服务正常运行,也可以用git手动完成备份本地,是不是很贴心啊。

最后介绍的是设置仓库IP白名单,首先搞明白啥意思。IP白名单是对IP范围开设的白名单,通过设置IP白名单能大大增强您的仓库的安全性; 只有在IP白名单范围内的仓库访问才是允许的,除此之外其他IP发起的访问一律被拒绝。这是最简单的一种IP白名单格式,如将您的个人家庭电脑的IP添加到白名单中,比如:117.78.39.149。


其中涉及到CIDR格式,也叫无类别遇间路由需要你理解它

也就是当您的服务器在一个局域网内而且使用CIDR路由时,这时您可以指定局域网的32位出口IP以及一个指定网络前缀的位数; 这样,从同一个IP发起的请求,只要网络前缀同您设定的前缀部分相同,即可视为来自同一授信范围从而被接受; 举例:比如222.80.18.18/25,这样即使在同一个IP局域网下的他人的服务器(网络前缀位数不是前25位)依然能够被拦截。

相关文章
|
5月前
|
弹性计算 Prometheus 监控
从自建开源 Prometheus 迁移到阿里云托管 Prometheus 服务
阿里云可观测监控 Prometheus 版提供高性能、高可用、全托管的监控服务,对接开源生态,支持 Kubernetes、ECS 等场景,解决了自建 Prometheus+Thanos 高成本、运维复杂的问题。本文讨论在各个典型场景下的迁移方案。
12068 71
|
4月前
|
数据采集 弹性计算 Prometheus
重磅升级!从自建Prometheus到阿里云托管:无缝迁移,监控能力全面飞跃
【8月更文挑战第2天】如何从自建开源 Prometheus 迁移到阿里云托管 Prometheus 服务
99 2
|
7月前
|
弹性计算 Prometheus 监控
基于 Prometheus 的超算弹性计算场景下主机监控最佳实践
超算快速弹性伸缩场景下,如何构建一套准确、快速、可靠的监控体系成为关键点。阿里云在超算场景的主机监控落地实践,解决超算场景面临的挑战,交付一套可靠和全面的主机监控体系。
60359 21
|
7月前
|
弹性计算 Kubernetes Cloud Native
【阿里云弹性计算】阿里云ECS与容器技术融合:打造敏捷的云原生基础设施
【5月更文挑战第21天】阿里云ECS结合容器技术(如Docker和Kubernetes),助力企业构建敏捷云原生基础设施。ECS提供高性能服务器,支持容器快速部署和自动化管理,实现应用的高可用性和可维护性。通过二者协同,企业能打造高效、可扩展的应用,加速数字化转型。示例代码展示了在ECS上使用Docker和Kubernetes部署云原生应用的过程。
118 3
|
7月前
|
存储 Cloud Native 大数据
国内独家|阿里云瑶池发布ClickHouse企业版:云原生Serverless新体验
全面升级为云原生架构,支持云原生按需弹性Serverless能力,解决了长期困扰用户的集群扩展效率和平滑性问题。
国内独家|阿里云瑶池发布ClickHouse企业版:云原生Serverless新体验
|
专有云
阿里云最新产品手册——阿里云核心产品——专有云飞天企业版——全栈式灾备管理平台
阿里云最新产品手册——阿里云核心产品——专有云飞天企业版——全栈式灾备管理平台自制脑图
278 1
|
弹性计算 Cloud Native Linux
【华为云原生入门级认证】第 2 章 云原生基础设施之容器技术
【华为云原生入门级认证】第 2 章 云原生基础设施之容器技术
232 0
|
Kubernetes Cloud Native 网络协议
erda 开源产品纳管自建k8s集群(一)
Erda 是新一代数字化云原生 PaaS 平台,其核心包含三大模块:应用(微服务)研发治理平台、快数据治理平台和混合云管理平台。是基于 K8s 的应用开发管理平台,而并非一个 K8s 发行版本,也不是一个 K8s 管理平台。
|
存储 SQL 缓存
云数据库ClickHouse:从云托管到云原生背后的核心技术解析
阿里云数据库ClickHouse自从上线以来,已经走过了两年多的时间,期间我们积淀了大量的云上客户案例,在长期的客户服务支持中也对ClickHouse数据库生态有了非常深刻的认知。在充分了解现有产品的生态和客户实践使用痛点后, 我们对开源ClickHouse数据库做了全新的架构升级,接下来将为用户带来全新的云原生版本ClickHouse数据库。
1052 0
云数据库ClickHouse:从云托管到云原生背后的核心技术解析
|
边缘计算 弹性计算 资源调度
基于阿里ECS云服务搭建KubeEdge云边异构环境心得
随着云计算技术的飞速发展,人们对服务的需求逐渐增加,在边缘计算的概念被提出后,针对不同任务的计算和卸载、服务的QoS等相关问题迅速成为该领域的研究热点,研究人员的目光也逐渐由云端转向边缘。由华为公司提出的KubeEdge平台为边缘计算提出了新的解决方案,本文基于阿里云提供的ECS云平台,以及本地VM和树莓派搭建了KubeEdge云边异构环境,用于支持未来的研究内容,并提出本人在搭建过程中的心得和体会。
685 0
基于阿里ECS云服务搭建KubeEdge云边异构环境心得