GitLAB使用_自己gitlab命名空间

GitLab使用

目录

实验环境

1台centos7.6虚机
gitlab/gitlab-ce:15.0.3-ce.0 
1
2

实验软件（无）

1、GitLab组织配置

1.Namespaces 名称空间

不同namespace的项目，其url是不一样的。

用户自己有一个默认的namespace的：

2.Members成员

gitlab里的权限一般会和ldap做集成的。

这里是有很多role可以去选择的：

3.Groups组管理

之前在删除某个gitlab离职用户后，他的项目也被删除了。因此，创建项目一般建议都放置在组里；

2、GitLab项目管理

配置group名称最好与项目组有关的，例如业务的简称等等。项目组的类型分为 Private、Internal、Public三种类型。

• Private 私有类型（当group为私有类型，后面组下面的项目都是私有类型）
• Public 公开类型

创建组

生成代码

来到https://start.spring.io网站，初始化一个springboot项目：

生成项目代码：

下载项目代码：

创建项目

在这个页面可以创建一个空的项目、根据一个模板创建项目、导入一个已存在的项目（Gitlab、GitHub等系统）

创建项目：

创建一个叫做devops-demo-service私有类型项目

将项目代码推送到刚创建的项目里

• 我们看下刚才创建的项目代码

将demo.zip解压，能看到这个demo目录只是一个纯目录，而不是git仓库

• 利用刚才创建目录后的提示，将demo内容推送到新创建的项目里去

cd existing_folder
git init --initial-branch=main #这里注意下，git的这个--initial-branch参数需要git高一点的版本，否则会报错。
git remote add origin http://172.29.9.101:8076/devops6/devops-demo-service.git
git add .
git commit -m "Initial commit"
git push -u origin main
1
2
3
4
5
6

推送过程：

这里注意下，git的这个–initial-branch参数需要git高一点的版本，否则会报错。

当前git版本：

但是，这里也可以使用其它方式来实现这个效果：

执行过程如下：

注意：自己pc上已经有了这个签名配置了，这里就不再重新配置了哦。

cd demo
git init
git checkout -b  main
git remote add origin http://172.29.9.101:8076/devops6/devops-demo-service.git
git add .
git commit -m "Initial commit"
git push -u origin main
1
2
3
4
5
6
7

来到项目这里，发现已经可以看见代码了：

这边我们再推送一个README.md文件到仓库：

Win@DESKTOP-VUMV922 MINGW64 ~/Desktop/demo (main)
$ echo devops6 > README.md

Win@DESKTOP-VUMV922 MINGW64 ~/Desktop/demo (main)
$ git add .
warning: in the working copy of 'README.md', LF will be replaced by CRLF the next time Git touches it

Win@DESKTOP-VUMV922 MINGW64 ~/Desktop/demo (main)
$ git commit -m "add Readme"
[main 5617ddd] add Readme
 1 file changed, 1 insertion(+)
 create mode 100644 README.md

Win@DESKTOP-VUMV922 MINGW64 ~/Desktop/demo (main)
$ git push
Enumerating objects: 4, done.
Counting objects: 100% (4/4), done.
Delta compression using up to 8 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 273 bytes | 273.00 KiB/s, done.
Total 3 (delta 1), reused 0 (delta 0), pack-reused 0
To http://172.29.9.101:8076/devops6/devops-demo-service.git
   52558bc..5617ddd  main -> main

Win@DESKTOP-VUMV922 MINGW64 ~/Desktop/demo (main)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

到项目上确认下：（符合预期）

创建特性分支

为什么要拉取分支？ 一个分支不够吗？ 一般我们使用 master 主干分支存放最新的能够发布生产的代码，而单独创建一些特性分支来做项目需求任务的开发分支。 这样的好处是防止主干分支污染，对分支起到了保护的作用。

下面进入 devops-demo-service 项目主页，然后基于主干分支master，创建特性分支feature-dev-01。操作如下：

特性分支开发与提交

查看当前本地分支，发现没有刚刚远程创建的 feature-dev-01 分支。

Win@DESKTOP-VUMV922 MINGW64 ~/Desktop/demo (main)
$ git branch -a
* main
  remotes/origin/main

Win@DESKTOP-VUMV922 MINGW64 ~/Desktop/demo (main)
$
1
2
3
4
5
6
7

git pull 同步远程仓库所做的更新到本地， 这样远程的feature-dev-01分支就同步到了本地。然后我们使用 git checkout feature-dev-01切换到特性分支。

Win@DESKTOP-VUMV922 MINGW64 ~/Desktop/demo (main)
$ git pull
From http://172.29.9.101:8076/devops6/devops-demo-service
 * [new branch]      feature-dev-01 -> origin/feature-dev-01
Already up to date.

Win@DESKTOP-VUMV922 MINGW64 ~/Desktop/demo (main)
$ git branch -a
* main
  remotes/origin/feature-dev-01
  remotes/origin/main

Win@DESKTOP-VUMV922 MINGW64 ~/Desktop/demo (main)
$ git checkout feature-dev-01
Switched to a new branch 'feature-dev-01'
branch 'feature-dev-01' set up to track 'origin/feature-dev-01'.

Win@DESKTOP-VUMV922 MINGW64 ~/Desktop/demo (feature-dev-01)
$
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

我们更改下README.md文件内容，然后将更改内容提交到远程仓库。

Win@DESKTOP-VUMV922 MINGW64 ~/Desktop/demo (feature-dev-01)
$ echo 情出自愿-事过无悔 > README.md

Win@DESKTOP-VUMV922 MINGW64 ~/Desktop/demo (feature-dev-01)
$ git add .
warning: in the working copy of 'README.md', LF will be replaced by CRLF the next time Git touches it

Win@DESKTOP-VUMV922 MINGW64 ~/Desktop/demo (feature-dev-01)
$ git commit -m "modify README.md"
[feature-dev-01 7cf5639] modify README.md
 1 file changed, 1 insertion(+), 1 deletion(-)

Win@DESKTOP-VUMV922 MINGW64 ~/Desktop/demo (feature-dev-01)
$ git push origin feature-dev-01
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 8 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 294 bytes | 294.00 KiB/s, done.
Total 3 (delta 1), reused 0 (delta 0), pack-reused 0
remote:
remote: To create a merge request for feature-dev-01, visit:
remote:   http://172.29.9.101:8076/devops6/devops-demo-service/-/merge_requests/new?merge_request%5Bsource_branch%5D=feature-dev-01
remote:
To http://172.29.9.101:8076/devops6/devops-demo-service.git
   5617ddd..7cf5639  feature-dev-01 -> feature-dev-01
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

我们来到gitlab项目页面，刷新下：

这样我们就把本地的特性分支开发的代码提交到了远程特性分支中了， 接下来对应该对该特性分支进行测试验证，没问题后合并到主干分支。

特性分支合并操作

将特性分支 feature-dev-01 代码合并到主干分支main Merge Request。

在这个页面，选择源分支和目标分支。

在这个页面：

• 1 指定合并请求的标题
• 2 描述信息，一般都是变更信息
• 3 指定主管进行审核（最终该用户决定是否合并）
• 4 指定进行代码审查的同事
• 5 合并成功后删除源分支（最后很定要删除源分支，可以先保留一个版本后再删除，此处最好取消勾选）

交合并后，由管理员审查进行合并。

合并后的效果： 特性分支的更改已经同步到了主干分支。

到此一个基本的项目开发提交代码过程就已经完成了。（多熟悉一下这个过程）

分支策略管理最佳实践

还是要避免一个情况，防止main分支被污染。

最佳实践：特性分支开发，版本分支发布。

案例：

接着继续以main分支创建2个特性分支：feature-dev-02，feature-dev-03

以main分支创建1个版本分支：RELEASE-1.1.1

此时，在gitlab web ide里修改特性分支feature-dev-02/03里的代码并提交。

然后，将2个特性分支代码feature-dev-02/03提交合并到版本分支RELEASE-1.1.1里

此时，版本分支经过dev-stag-prod环境测试无问题后，就打上一个tag，然后合并到主干分支中去。

确认生产发布成功了，这个时候，你打上一个tag。

验证：

3、GitLab用户管理

gitlab重置用户密码

(测试成功)-2022.5.13

1、web界面方式

2、控制台方式

gitlab版本：gitlab/gitlab-ce:14.9.3-ce.0
1