Git结合Gitee的企业开发模拟

本系列有两篇文章:

  1. 一是另外一篇《快速使用Git完整开发》,主要说明了关于Git工具的基础使用,包含三板斧(git addgit commitgit push)、Git基本配置、版本回退、分支管理、公钥与私钥、远端仓库和远端分支、忽略文件、命令别名、标签等内容。
  2. 二是本篇,本文主要说明了Gitgitee开发协作的实践操作,会带领您从0开始演示企业中的项目开发过程(简略)。

1.多人协作一(共享分支)

  1. 目标:master分支下file.txt文件新增text_1text_2文本。

  2. 实现:由开发者1增加text_1,由开发者2增加text_2。这里我们可以使用两台电脑,或者使用云服务器来真实模拟两名开发者。

  3. 条件:在一个分支下完成。

1.1.创建远端仓库

创建一个远端仓库,该仓库默认有主分支master。并且仓库内有文件test_code,内容如下:

    I am a code.

1.2.创建远端分支

首先在自己的项目仓库中创建一个基于master远端分支的debug远端分支。

现在远端仓库有两个分支,一个为master远端分支,另外一个为debug远端分支。

此时对于还没有拉取的两个开发者来说,都各有一个master本地分支和一个origin/master远端分支(git branch是查看本地分支,而git branch -r是查看远端分支)。

    $ git branch -rorigin/HEAD -> origin/masterorigin/master

而我们所有的操作基本都是在本地操作的,此时两名开发者都需要使用git pull拉取远程的仓库。

此时再次运行就可以显示远端仓库的远端分支,但是我们可以注意到并没有增加本地分支。

    $ git branch -rorigin/HEAD -> origin/masterorigin/debugorigin/master$ git branch* master

1.3.开发者1操作

此时肯定是不可能在本地直接切换到远端分支的,因此就需要自己创建一个debug分支,使用命令git checkout -b debug origin/debug

此时本地就有debug本地分支了,并且也切换过去了。

    $ git checkout -b debug origin/debugSwitched to a new branch 'debug'branch 'debug' set up to track 'origin/debug'.

这实际上就是在创建分支的同时将本地分支和远端分支建立联系/关联,可以使用git branch -vv来查看是否有联系/关联。

    $ git branch -vv* debug  SHA-1值 [origin/debug] commit内容1master SHA-1值 [origin/master] commit内容2

补充:建立联系/关联的意义是可以直接使用短命令git pushgit pull,而不是完整的长命令。

此时已经处于debug分支上,然后使用vim修改。

在这里插入图片描述

    $ git branch* debugmaster$ vim test_code$ git add --all$ git commit -m "日志:我是开发者1,我来提交代码"

然后再进行push操作(由于有关联,因此可以直接使用)

回去查看远程仓库的内容,可以发现debug远端分支内已经发生了修改,并且领先master远端分支。

在这里插入图片描述

1.4.开发者2操作

也同样需要建立联系/关联,但是这里我们演示不使用联系/关联的情况。

首先直接创建本地分支:

    $ git checkout -b debugSwitched to a new branch 'debug'

此时就没办法直接使用短命令pull

    $ git pullThere is no tracking information for the current branch.Please specify which branch you want to merge with.See git-pull(1) for details.git pull <remote> <branch>If you wish to set tracking information for this branch you can do so with:git branch --set-upstream-to=origin/<branch> debug

可以按照提示来链接本地分支和远端分支:

$ git branch --set-upstream-to=origin/<branch> debug debug$ git branch --set-upstream-to=origin/debug debug
branch 'debug' set up to track 'origin/debug'.

然后不要急着使用pull,我们打开test_code写入以下内容:

    I am a code.test_2

然后照旧使用git addgit commit -m "日志:我是开发者2,我也来提交代码"

再使用git push,这个时候发现Git拒绝了该请求,这是因为发生了分支冲突。

因此必须使用pull拉取,手动解决冲突,然后再进行addcommitpush

debug的最后一次提交就已经是我们所要的完整代码了。

在这里插入图片描述

1.5.合并到master

此时debug远端分支已经准备完毕,但是master远端分支还没有修改成功。

此时有两种做法:

1.5.1.做法一

一种是直接在本地合并然后push到远端仓库。

  1. 首先是将master分支合并到debug分支,避免debug分支和master分支发生冲突(因为还有其他分支的存在)

  2. 切换到master,通过pull保持最新,然后在本地的debug上解决冲突

  3. debug分支合并到master分支,此时master就有了修改

  4. 然后进行push即可

  5. 此时远端和本地debug分支就没有用了,可以在远端仓库中删除和在本地仓库使用git branch -d debug

  6. 最后两名开发者同时使用pull命令

1.5.2.做法二

另外一种方法就是在gitee提交PR合并申请单,由管理员来做审核后来merge(可以直接在远端仓库上操作,这种方式更加安全)。

在这里插入图片描述

2.多人协作二(私有分支)

目标:远程master分支下新增function1function2文件。

  1. 实现:由开发者1新增function1文件,由开发者2新增function2文件。

  2. 条件:在不同分支下协作完成(每个开发者有自己的分支,或者一个分支一个功能)。

首先要明白有两种方法:

  1. 创建远端分支(正式工作时推荐,可以保证一定是基于远端master上最新的代码)

  2. 创建本地分支然后push(基于本地master分支不一定是最新的代码)

但是我们在本次演示中使用第二种方法。

2.1.开发者1

  1. pull后创建基于master本地分支的feature-1本地分支,此时就没有办法使用链接了,因为我们没有在远端仓库创建远端分支,没有办法链接,因此我们现在的状态是没有办法使用短命令的。

  2. 然后创建一个function1文件,内部写入内容

  3. 然后使用addcommit命令

  4. 由于没有链接(也无法链接,远端仓库没有远端分支),所以要使用长命令,git push origin feature-1直接将本地分支推送到远端仓库,可以给远端仓库创建远端分支。

    //开发者1$ git pull$ git checkout -b feature-1Switched to a new branch 'feature-1'$ git branch* feature-1master$ vim function1$ git add --all$ git commit -m "日志:开发者1的function1文件"$ git push origin feature-1

此时就可以看到远端仓库多了一个远端分支。

在这里插入图片描述

2.2.开发者2

  1. 此时开发者2也进行一样的工作,但是此时master本地分支不是最新的,因此就需要在master本地分支上pull

  2. 剩下的工作就和开发者1是一样的

    //开发者2$ git branch* master$ git branch -rorigin/HEAD -> origin/masterorigin/master$ git pull$ git branch* master$ git branch -rorigin/HEAD -> origin/masterorigin/feature-1origin/master$ git checkout -b feature-2 Switched to a new branch 'feature-2'$ vim function2$ git add --all$ git commit -m "日志:开发者2的function2文件" $ git push origin feature-2

此时就可以看到远端仓库又多了一个远端分支。

在这里插入图片描述

2.3.合并到master

假设这个时候有一种情况,开发者2发生意外情况,没有办法现在合并到master远端分支。

  1. 此时开发者1使用git pull把开发者2创建的远端分支feature-2拉取过来(这里之所以可以直接使用短命令,是因为:a.拉取分支内的内容才需要的建立链接 b.但是拉取远端仓库内容的时候就不需要建立链接)

  2. 开发者1新使用命令git checkout -b feature-2 origin/feature-2创建、链接并且切换到一个feature-2的本地分支。

  3. 这个时候开发者1就拥有了开发者2的文件,可以继续帮开发者2继续开发(比如加入某些代码或删除,然后再addcommit,并且直接使用短命令push即可)

  4. 如果后续开发者2回来了,就需要再一次将feature-2origin/feature-2进行链接,然后pull将开发者1帮忙的部分从远端分支拉取

    //开发者1$ git pull$ git branch -a* feature-1masterremotes/origin/HEAD -> origin/masterremotes/origin/feature-1remotes/origin/feature-2remotes/origin/master$ git checkout -b feature-2 origin/feature-2Branch feature-2 set up to track remote branch feature-2 from origin.Switched to a new branch 'feature-2'$ git branch -afeature-1* feature-2masterremotes/origin/HEAD -> origin/masterremotes/origin/feature-1remotes/origin/feature-2remotes/origin/master$ git vim function2$ git add --all$ git commit -m "日志:开发者1帮助开发者2的开发"$ git push

此时远端仓库就有了推送

在这里插入图片描述

    $ git branch --set-upstream-to=origin/feature-2 feature-2$ git pull

此时开发者2就可以看到开发者1半自己开发的部分了。

  1. 开发者2还可以继续进行自己的开发,照常使用addcommit和短命令push即可

在这里插入图片描述

  1. 现在在远端仓库中,有两个新增加的分支,并且两名开发者都准备好各自的私有分支内的代码文件,最后只需要提交PR给管理者,管理员再远程仓库上做代码审核和冲突修改和分支合并即可

在这里插入图片描述

  1. 此时由审查员和测试员通过审查和测试才可以正式合并进master,此时就完成了合并

在这里插入图片描述


在这里插入图片描述

  1. 此时对于开发者2来说,理论上也是可以像开发者1一样操作的,但是有可能发生冲突,因此最好是在本地将远端分支最新的master合并进来,防止冲突在master上解决,然后使用长命令push(分支合并会自动commit),再提交PR上去。
    $ git checkout master$ git pull$ git branchdebugfeature-2* master$ git checkout feature-2$ git merge master//然后解决冲突$ git push origin feature-2

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

3.远程分支删除后…

前面开发者1和开发者2开发完后,假设开发者2因为请假次数太多被辞了(悲痛~),这个时候管理者也把他的远端工作分支删除了,但是这个时候我们会发现一个问题:在本地使用git branch -a/-r依旧可以看到这个远端分支。

在这里插入图片描述

    $ git branch -afeature-1feature-2* masterremotes/origin/HEAD -> origin/masterremotes/origin/feature-1remotes/origin/feature-2remotes/origin/master

那么这么办呢?可以使用git remote show origin,该命令用于显示远程仓库 origin 的详细信息,包括该远程仓库与本地仓库的分支关联、最新提交等。

    $ git remote show origin* remote originFetch URL: https://gitee.com/limou3434/limou-c-test-code.gitPush  URL: https://gitee.com/limou3434/limou-c-test-code.gitHEAD branch: masterRemote branches:feature-1                     trackedmaster                        trackedrefs/remotes/origin/feature-2 stale (use 'git remote prune' to remove)Local branches configured for 'git pull':feature-2 merges with remote feature-2master    merges with remote masterLocal refs configured for 'git push':feature-1 pushes to feature-1 (up to date)master    pushes to master    (up to date)

这里就有提示使用git remote prune [远端仓库名]去移除旧分支,即可裁剪掉显示在本地机器的旧的远端分支。

4.企业模型协作(真实模拟)

4.1.协作模式

软件开发工程师开发团队
软件测试工程师测试团队
软件运维工程师运维团队
Plan(规划)
Code(代码)
Build(构建)
Test(测试)
Relese(发布)
Deploy(部署)
Operate(维护)

在传统的IT组织下,开发团队(Dev)和运维团队(Ops)之间的诉求会矛盾:

  1. 开发团队追求变化(尤其是追求敏捷编程思想的),可能需要持续交付作为目标

  2. 运维团队追求稳定,可能强调稳定且变更控制

这就会导致一道无形的”墙“被堆积起来,不利于IT价值的最大化,为了解决这一鸿沟,就需要在企业文化、开发工具、和代码实践等方面做变革——DevOps(重视“软件开发人员”和“运维技术人员”之间沟通的文化、运动、惯例)出现了。通过自动化的“软件交付”和“架构变更”的流程,来使得构造、测试、发布软件可以快捷、频繁、可靠。

DevOps开发过程中包含计划、编码、构建、测试、预发布、发布、运维、监控

而做到DevOps就极其需要类似Git这样可以快速迭代版本和维护不同版本的。

4.2.开发环境

对于开发人员来说有几个常用的环境需要了解:

  1. 开发环境:是程序员专门用于日常开发的服务器,为了开发调试方便,一般打开全部错误报告和测试工具,是最基础的环境。

  2. 测试环境:一个程序在测试工作不正常,那么就不可以发布到生产机上。该环境是开发环境到生产环境的过度环境。

  3. 预发布环境:该环境是为避免因测试环境和线上环境的差异带来的缺陷而设立的环境。其配置等基本和生产环境一致,目的就是让正式开发的时候更有把握。所以预发布环境是你的产品质量的最后一道防线,下一步项目就要上线了。要注意预发布环境的服务器不再线上集成服务器的范围之内,是单独的一些机器。

  4. 生产环境:是指正式提供对外服务的线上环境,在PC端和手机端能访问到的APP基本都是生产环境。

  5. 灰度环境:有的大公司还存在灰度环境或者叫仿真环境。

  6. 其他环境:…

4.3.分支规范

环境有了概念之后,Git分支就会根据不同的环境进行规范设计。

一般来说:

分支合并
分支合并
分支合并
Tag1
Tag2
Tag3
hotfix(紧急修复分支)本地环境
release(预发分支)预发布/测试环境
feature(需求开发分支)本地环境
develop(开发分支)开发环境
master(主分支)生产环境
修复
1.0[出现紧急问题]
1.0(带补丁)
debug6
提交1
提交2
提交3
提交4
提交5
提交6
提交7
提交8
提交9
debug1
debug2
debug3
debug4
debug5
0.1
0.2

注意:以上只是常用的Git Flow模型,真实环境由企业而定(并且有部分细节被忽略了)。

4.3.1.master分支

  1. 给分支为只读分支,并且只有一个,用于部署到正式发布环境,由合并release分支得到

  2. 主分支作为稳定的唯一代码,任何情况下不允许直接在master上修改代码

  3. 产品功能全部实现后,最终在master分支对外发布,另外所有在master的推送都应该打上tag记录,方便追朔(也就是发布一次就要打上标签)

  4. master分支不可删除

4.3.2.develop分支

  1. develop分支作为开发分支,是基于master分支创建的只读唯一分支,始终保持最新完成的bug修复后的代码,可部署到开发环境对应集群

  2. 可根据需求大小程度确定是由feature分支合并,还是直接在上面开发(后者不太推荐)

4.3.3.feature分支

  1. feature分支通常都作为新功能和新特性开发分支,是以develop分支为基础创建的

  2. 命名一般以feature/开头,建议的命名规范为:feature/user_createtime_feature

  3. 新功能开发完成后,开发者需要将feature分支合并到develop分支

  4. 一旦新需求发布上线后,便要将该分支删除

4.3.4.release分支

  1. release分支为预发布分支,基于本次上线所有的feature分支合并到develop分支后,再基于develop分支创建,可以部署到测试或预发布集群

  2. 命名也有规范,一般release/开头,建议命名规则为:release/version_publishtime

  3. release分支主要用于提交给测试人员进行功能测试。发布提测阶段,会以release分支为基准进行提测

  4. release分支测试出问题,则需要回归develop分支查看是否存在此问题

  5. release分支属于临时分支,产品上线后可以选择删除

4.3.5.hotfix分支

  1. hotfix分支是线上出现紧急bug问题时,提交补丁时使用,又叫”补丁分支“,需要基于master分支创建hotfix分支

  2. 命名hotfix/开头,建议命名规范为:hotfix/user_createtime_hotfix

  3. 当问题修复完成后,需要合并到develop分支并推送到远程。一旦修复测试通过,就通过develop远端合并到master远端分支,并且结束后需要将其删除

还有一些其他的大企业有不同的模型。

4.4.管理实战

4.4.1.创建账号

创建两个Gitee账号,一个为公司老板账号limou3434,一个为员工账号Dimou3434(绑定不同的邮箱)。

并且最好准备两个浏览器,一个登录老板账号,一登录员工账号。

最好准备一个本地机器和服务器(模拟老板和员工各自的本地环境,有其他方案替代也可以…)

4.4.2.创建企业空间

首先我们需要创建一个企业空间,并且创建好空间内的仓库。

在这里插入图片描述
在这里插入图片描述

在这里插入图片描述


在这里插入图片描述

一个企业会有多个项目,在一个项目中需要多个仓库,这里我们可以先建立一个仓库。

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

发送员工邀请链接,让一名员工进来企业空间。

在这里插入图片描述

另外一名员工在登录自己gitee账号后,需要打开该链接填写姓名后加入。

在这里插入图片描述
在这里插入图片描述

同意员工加入。

在这里插入图片描述
在这里插入图片描述

项目和仓库也需要设置成员,这样相关的成员才可以使用该仓库的部分权限。

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

4.4.3.分支管理

此时我们设置的库有默认有5个分支,然后拉取到本地,创建featrue本地分支后,在上面进行开发,然后关联远端分支featrue进行提交。

老板在自己的企业空间上,检查提交,检查完成后,在远端仓库,把远端分支featrue的提交合并到远端分支develop上,老板为了规范,也”装模做样“的做了一次代码审核。

在这里插入图片描述

在这里插入图片描述

好了,老板自己审核好自己的代码后,进行了合并。

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

此时测试人员(假设是员工1)需要测试老板的代码,那么就需要得到本地的release,因此他需要先请求远端分支release是基于远端分支develop分裂出来的,因此提交了代码评审。

在这里插入图片描述
在这里插入图片描述

此时如果测试人员测试通过了老板的代码,那么就可以请求把release远端分支的代码和合并到master远端分支上的,员工使用PR告知老板,然后老板直接通过了该审查。

在这里插入图片描述

在这里插入图片描述

并且测试分支也被删除了。

在这里插入图片描述

当然,如果release远端分支出现了问题,就需要回去检查develop远端分支是否存在这个问题,如果有问题,就从feature远端分支上进行debug然后合并到develop远端分支,然后将新的develop分支合并到release远端分支,在进行测试,知道没有bug

剩下的几个分支和相关流程实际上和我们之前讲的大差不差,您可以自己试一试…

注意:最后再强调一遍,只有适合自己团队的分支模型,而没有最完美的分支模型。

4.5.代码部署

这个可以在流水线里研究(不过在gitee上是需要付费的),相关的操作请查看gitee的文档。

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.rhkb.cn/news/115517.html

如若内容造成侵权/违法违规/事实不符,请联系长河编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

迈向无限可能, ATEN宏正领跑设备切换行业革命!

随着互联网在各个领域的广泛应用,线上办公这一不受时间和地点制约、不受发展空间限制的办公模式开始广受追捧,预示着经济的发展正朝着新潮与活跃的方向不断跃进。当然,在互联网时代的背景下,多线程、多设备的线上办公模式也催生了许多问题:多设备间无法进行高速传输、切换;为保…

直播预约|哪吒汽车岳文强:OEM和Tier1如何有效对接网络安全需求

信息安全是一个防护市场。如果数字化程度低&#xff0c;数据量不够&#xff0c;对外接口少&#xff0c;攻击成本高&#xff0c;所获利益少&#xff0c;自然就没有什么攻击&#xff0c;车厂因此也不需要在防护上花费太多成本。所以此前尽管说得热闹&#xff0c;但并没有太多真实…

软技能的重要性:在面试中展示团队合作与沟通能力

&#x1f337;&#x1f341; 博主猫头虎 带您 Go to New World.✨&#x1f341; &#x1f984; 博客首页——猫头虎的博客&#x1f390; &#x1f433;《面试题大全专栏》 文章图文并茂&#x1f995;生动形象&#x1f996;简单易学&#xff01;欢迎大家来踩踩~&#x1f33a; &a…

故事营销要搞,但不要迷恋于故事

故事营销要搞&#xff0c;但不要迷恋于故事【安志强趣讲274期】 趣讲大白话&#xff1a;迷恋故事就输了 **************************** 看了策划界有名的李金斗的《故事营销》 真心讲写的非常一般 东拼西凑的 把三个东西要梳理一下&#xff1a; 1、品牌调性&#xff1a;就是以某…

ZooKeeper集群环境搭建

&#x1f947;&#x1f947;【大数据学习记录篇】-持续更新中~&#x1f947;&#x1f947; 个人主页&#xff1a;beixi 本文章收录于专栏&#xff08;点击传送&#xff09;&#xff1a;【大数据学习】 &#x1f493;&#x1f493;持续更新中&#xff0c;感谢各位前辈朋友们支持…

Jetpack Compose 自定义 好看的TabRow Indicator

背景 Jetpack Compose 提供了强大的 Material Design 组件,其中 TabRow 组件可以用于实现 Material Design 规范的选项卡界面。但是默认的 TabRow 样式可能无法满足所有场景,所以我们有时需要自定义 TabRow 的样式。 Jetpack Compose 中使用 TabRow 简单使用 TabRow 一般可以…

新手练习python+selenium自动化测试实战项目【还有其他项目】

说明&#xff1a;本项目采用流程控制思想&#xff0c;未引用unittest&pytest等单元测试框架 【项目都放在最下面小卡片了&#xff0c;有需要可以自取】 一.项目介绍 目的 测试某官方网站登录功能模块可以正常使用 用例 1.输入格式正确的用户名和正确的密码&#xff0c;验…

Stable Diffusion 提示词技巧

文章目录 背景介绍如何写好提示词提示词的语法正向提示词负向提示词 随着AI技术的不断发展&#xff0c;越来越多的新算法涌现出来&#xff0c;例如Stable Diffusion、Midjourney、Dall-E等。相较于传统算法如GAN和VAE&#xff0c;这些新算法在生成高分辨率、高质量的图片方面表…

Gazebo仿真环境下的强化学习实现

Gazebo仿真环境下的强化学习实现 主体源码参照《Goal-Driven Autonomous Exploration Through Deep Reinforcement Learning》 文章目录 Gazebo仿真环境下的强化学习实现1. 源码拉取2. 强化学习实现2.1 环境2.2 动作空间2.3 状态空间2.4 奖励空间2.5 TD3训练 3. 总结 1. 源码…

HTTP协议详解:互联网通信背后的规则与秘密

个人主页&#xff1a;insist--个人主页​​​​​​ 本文专栏&#xff1a;网络基础——带你走进网络世界 本专栏会持续更新网络基础知识&#xff0c;希望大家多多支持&#xff0c;让我们一起探索这个神奇而广阔的网络世界。 目录 一、HTTP协议的基本概念 二、HTTP协议的主要特…

web题型

本文在别人的基础上对于一些地方做了一点补充 0X01 命令执行 漏洞原理 没有对用户输入的内容进行一定过滤直接传给shell_exec、system一类函数执行 看一个具体例子 cmd1|cmd2:无论cmd1是否执行成功&#xff0c;cmd2将被执行 cmd1;cmd2:无论cmd1是否执行成功&#xff0c;cm…

SpringBoot项目(jar)部署,启动脚本

需求 SpringBoot项目&#xff08;jar&#xff09;部署&#xff0c;需要先关闭原来启动的项目&#xff0c;再启动新的项目。直接输入命令&#xff0c;费时费力&#xff0c;还容易出错。所以&#xff0c;使用脚本启动。 脚本 脚本名&#xff1a;start.sh 此脚本需要放置在jar包…

【算法】递归的概念、基本思想

创作不易&#xff0c;本篇文章如果帮助到了你&#xff0c;还请点赞 关注支持一下♡>&#x16966;<)!! 主页专栏有更多知识&#xff0c;如有疑问欢迎大家指正讨论&#xff0c;共同进步&#xff01; &#x1f525;c系列专栏&#xff1a;C/C零基础到精通 &#x1f525; 给大…

JavaScript Web APIs-01学习

复习&#xff1a; splice() 方法用于添加或删除数组中的元素。 **注意&#xff1a;**这种方法会改变原始数组。 删除数组&#xff1a; splice(起始位置&#xff0c; 删除的个数) 比如&#xff1a;1 let arr [red, green, blue] arr.splice(1,1) // 删除green元素 consol…

ASUS华硕VivoBook15笔记本V5200EA_X515EA原装出厂Win11预装OEM系统

华硕11代酷睿笔记本电脑VivoBook_ASUSLaptop X515EA_V5200EA原厂Windows11系统 自带显卡、声卡、网卡、蓝牙等所有驱动、出厂主题壁纸、Office办公软件、华硕电脑管家MyASUS、迈克菲等预装程序 链接&#xff1a;https://pan.baidu.com/s/1yAEdA7aiuHK4CTdGLlSOKw?pwdo45a …

Azure - AzCopy学习

使用 AzCopy 将本地数据迁移到云存储空间 azcopy login 创建存储账号 ./azcopy login --tenant-id 40242385-c249-4746-95dc-4a0b64d49dc5这里的—tenant-id 在下面的地方查看&#xff1a;目录 ID&#xff1b;需要拥有Storage Blob Data Owner 的权限账号下可能会有很多目录&am…

编译工具:CMake(六) | 使用外部共享库和头文件

编译工具&#xff1a;CMake&#xff08;六&#xff09; | 使用外部共享库和头文件 步骤引入头文件搜索路径为 target 添加共享库 步骤 在/Compilation_tool/cmake 目录建立 t4 目录 建立src目录&#xff0c;编写源文件main.c&#xff0c;内容如下&#xff1a; #include <…

RabbitMQ入门

1、RabbitMQ概念简介 RabbitMQ是一个开源的消息代理和队列服务器&#xff0c;用来通过普通协议在完全不同的应用之间共享数据&#xff0c;RabbitMQ是使用Erlang语言来编写的&#xff0c;并且RabbitMQ是基于AMQP协议的。 AMQP协议模型 AMQP全称&#xff1a;Advanced Message Q…

浅探Android 逆向前景趋势~

前段时间&#xff0c;我和朋友偶然间谈起安卓逆向&#xff0c;他问我安卓逆向具体是什么&#xff0c;能给我们带来什么实质性的东西&#xff0c;我也和朋友大概的说了一下&#xff0c;今天在这里拿出来和大家讨论讨论&#xff0c;也希望帮助大家来了解安卓逆向。 谈起安卓逆向…

Annual Inspection

机动车年检流程【交警12123】APP 到【检查地方】门口墙上贴着 然后上缴钥匙&#xff0c;等待&#xff0c;本次等待不到半小时搞定&#xff0c;速度很满意&#xff0c; 发现检测人员把你的里程数纠正了。 给你的行驶证&#xff0c;打印这些字样&#xff1a;检验有效期至XXXX 再给…