GitLab版本控制
GitLab简介
GitLab是利用Ruby on Rails一个开源的版本管理系统,实现一个自托管的Git项目仓库,可通过Web界面进行访问公开的或者私人项目。
GitLab能够浏览源代码,管理缺陷和注释。可以管理团队对仓库的访问,它非常易于浏览提交过的版本并提供一个文件历史库。团队成员可以利用内置的简单聊天程序(Wall)进行交流。
它还提供一个代码片段收集功能可以轻松实现代码复用,便于日后有需要的时候进行查找。
项目各版本不可覆盖。
历史:
- GitLab在2011年10月由Dmitriy Zaporozhets和Valery Sizov创建。它在MIT许可证下发布,稳定版GitLab在2018年1月22日发布。
为什么要使用GitLab?
- GitLab是集中服务器上管理git存储库的一个好方法。 GitLab让您可以完全控制您的存储库或项目,并允许您自己决定是公共还是私有。
特征
-
GitLab免费托管您的(私人)软件项目。
-
GitLab是管理Git存储库的平台。
-
GitLab提供免费的公共和私人存储库,问题跟踪和维基。
-
GitLab是Git之上的一个用户友好的Web界面层,它提高了使用Git的速度。
-
GitLab提供了自己的持续集成(CI)系统来管理项目,并提供用户界面以及GitLab的其他功能
优点
-
GitLab提供了GitLab Community Edition版本,供用户在他们的代码所在的服务器上进行定位。
-
GitLab免费提供无限数量的私人和公共存储库。
-
代码片段可以共享项目中的少量代码,而不是共享整个项目。
缺点
-
在推拉(push/pull)仓库时,它并不像GitHub那么快。
-
从一个页面切换到另一个页面时,GitLab界面需要时间。
GitLab服务构成
Nginx:静态web服务器。
gitlab-shell:用于处理Git命令和修改authorized keys列表。
gitlab-workhorse: 轻量级的反向代理服务器。
logrotate:日志文件管理工具。
postgresql:数据库。
redis:缓存数据库。
sidekiq:用于在后台执行队列任务(异步执行)。
unicorn:GitLab Rails应用是托管在这个服务器上面的。
GitLab原理
其实gitlab的原理就是git的原理,GitHub也是基于Git的。
- Remote:远程仓库
- Repository:本地仓库
- index:暂存区
- workspace:工作区
-
Remote远程仓库:
远程仓库的内容可能被分布在多个地点的处于协作关系的本地仓库修改,因此它可能与本地仓库同步,也可能不同步,但是它的内容是最旧的 -
Repository本地仓库:
这里面保存了对象被提交过的各个版本,比起工作区和暂存区的内容,它更旧一些
git commit
后同步index的目录树到本地仓库,方便下一步通过git push
同步本地仓库与远程仓库的同步 -
index暂存区:
.git
目录下的index
文件,暂存区会记录git add
添加文件的相关信息(文件名、大小),不保存文件实体,通过id指向每个文件的实体,可以使用git status
查看暂存区的状态,暂存区标记了你当前工作区中那些内容是被git管理的
当你完成某个需求或者功能后需要提交代码,那么第一步就是通过git add
先提交到暂存区,被git管理 -
workspace工作区:
程序员进行开发改动的地方,是你当前看到的,内容也是最新的
平常我们开发就是拷贝远程仓库中的分支,基于该分支进行开发,在开发的过程就是在工作区的操作 -
总结:
任何对象都是在工作区中诞生和修改的
任何修改都是从进入index区才开始被版本控制的
只有把修改的代码提交到本地仓库,该修改才能在仓库中留下痕迹
与协助者分享本地的修改,可以push到远程仓库来共享
版本控制介绍
版本控制是指对软件开发过程中各种程序代码、配置文件及说明文档等文件变更的管理,是软件配置管理的核心思想之一。
版本控制最主要的功能就是追踪文件的变更。它将什么时候、什么人更改了文件的什么内容等信息忠实地了记录下来。每一次文件的改变,文件的版本号都将增加。除了记录版本变更外,版本控制的另一个重要功能是并行开发。软件开发往往是多人协同作业,版本控制可以有效地解决版本的同步以及不同开发者之间的开发通信问题,提高协同开发的效率。并行开发中最常见的不同版本软件的错误(Bug)修正问题也可以通过版本控制中分支与合并的方法有效地解决。
具体来说,在每一项开发任务中,都需要首先设定开发基线,确定各个配置项的开发初始版本,在开发过程中,开发人员基于开发基线的版本,开发出所需的目标版本。当发生需求变更时,通过对变更的评估,确定变更的影响范围,对被影响的配置项的版本进行修改,根据变更的性质使配置项的版本树继续延伸或产生新的分支,形成新的目标版本,而对于不受变更影响的配置项则不应发产生变动。同时,应能够将变更所产生的对版本的影响进行记录和跟踪。必要时还可以回退到以前的版本。例如当开发需求或需求变更被取消时,就需要有能力将版本回退到开发基线版本。在曾经出现过的季度升级包拆包和重新组包的过程中,其实就是将部分配置项的版本回退到开发基线,将对应不同需求的不同分支重新组合归并,形成新的升级包版本。
版本控制是软件配置管理的核心功能。所有置于配置库中的元素都应自动予以版本的标识,并保证版本命名的唯一性。版本在生成过程中,自动依照设定的使用模型自动分支、演进。除了系统自动记录的版本信息以外,为了配合软件开发流程的各个阶段。还需要定义、收集一些元数据来记录版本的辅助信息和规范开发流程,并为今后对软件过程的度量做好准备。当然如果选用的工具支持,这些辅助数据将能直接统计出过程数据,从而方便软件过程改进活动的进行。对于配置库中的各个基线控制项,应该根据其基线的位置和状态来设置相应的访问权限。一般来说,对于基线版本之前的各个版本都应处于被锁定的状态,如需要对它们进行变更,则应按照变更控制的流程来进行操作。
常用的版本控制工具:
- gitlab
- subversion
GitLab常用命令
gitlab-ctl start //启动全部服务
gitlab-ctl restart //重启全部服务
gitlab-ctl stop //停止全部服务
gitlab-ctl restart nginx //重启单个服务,如重启nginx
gitlab-ctl status //查看服务状态
gitlab-ctl reconfigure //使配置文件生效
gitlab-ctl show-config //验证配置文件
gitlab-ctl uninstall //删除gitlab(保留数据)
gitlab-ctl cleanse //删除所有数据,从新开始
gitlab-ctl tail <service name> //查看服务的日志
gitlab-ctl tail nginx //如查看gitlab下nginx日志
gitlab-rails console //进入控制台
部署GitLab
环境说明:
建议系统环境在2核4G及以上,我这里用4核8G的系统环境。
操作系统 | IP地址 | 服务 |
---|---|---|
Rock Linux 9 | 192.168.92.144 | GitLab |
环境准备:
关闭防火墙SELinux,配置阿里云的网络源
[root@localhost ~]# systemctl disable --now firewalld.service
[root@localhost ~]# setenforce 0
[root@localhost ~]# sed -i 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/selinux/config
[root@localhost ~]# sed -e 's|^mirrorlist=|#mirrorlist=|g' \
-e 's|^#baseurl=http://dl.rockylinux.org/$contentdir|baseurl=https://mirrors.aliyun.com/rockylinux|g' \
-i.bak \
/etc/yum.repos.d/rocky-*.repo
[root@localhost ~]# dnf makecache
GitLab部署流程:
#安装epel源
[root@localhost ~]# yum -y install epel-release
#安装git
[root@localhost ~]# yum -y install git
#安装依赖包
[root@localhost ~]# yum -y install git curl openssh-server openssh-clients postfix cronie python3-policycoreutils policycoreutils-python-utils perl
#删除现有的依赖包,安装centos7的‘policycoreutils-python’依赖包
[root@localhost ~]# rpm -e --nodeps policycoreutils-3.3-6.el9_0.x86_64
[root@localhost ~]# rpm -e --nodeps policycoreutils-python-utils-3.3-6.el9_0.noarch
[root@localhost ~]# wget http://mirror.centos.org/centos/7/os/x86_64/Packages/policycoreutils-python-2.5-34.el7.x86_64.rpm
[root@localhost ~]# rpm -ivh --nodeps policycoreutils-python-2.5-34.el7.x86_64.rpm
#启动postfix并设为开机自启
[root@localhost ~]# systemctl enable --now postfix.service
#下载gitlab的rpm包
[root@localhost ~]# wget https://mirrors.tuna.tsinghua.edu.cn/gitlab-ce/yum/el7/gitlab-ce-15.3.3-ce.0.el7.x86_64.rpm
#安装gitlab
[root@localhost ~]# rpm -ivh gitlab-ce-15.3.3-ce.0.el7.x86_64.rpm
warning: gitlab-ce-15.3.3-ce.0.el7.x86_64.rpm: Header V4 RSA/SHA1 Signature, key ID f27eab47: NOKEY
Verifying... ################################# [100%]
Preparing... ################################# [100%]
Updating / installing...
1:gitlab-ce-15.3.3-ce.0.el7 ################################# [100%]
It looks like GitLab has not been configured yet; skipping the upgrade script.
*. *.
*** ***
***** *****
.****** *******
******** ********
,,,,,,,,,***********,,,,,,,,,
,,,,,,,,,,,*********,,,,,,,,,,,
.,,,,,,,,,,,*******,,,,,,,,,,,,
,,,,,,,,,*****,,,,,,,,,.
,,,,,,,****,,,,,,
.,,,***,,,,
,*,.
_______ __ __ __
/ ____(_) /_/ / ____ _/ /_
/ / __/ / __/ / / __ `/ __ \
/ /_/ / / /_/ /___/ /_/ / /_/ /
\____/_/\__/_____/\__,_/_.___/
Thank you for installing GitLab!
GitLab was unable to detect a valid hostname for your instance.
Please configure a URL for your GitLab instance by setting `external_url`
configuration in /etc/gitlab/gitlab.rb file.
Then, you can start your GitLab instance by running the following command:
sudo gitlab-ctl reconfigure
For a comprehensive list of configuration options please see the Omnibus GitLab readme
https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/README.md
Help us improve the installation experience, let us know how we did with a 1 minute survey:
https://gitlab.fra1.qualtrics.com/jfe/form/SV_6kVqZANThUQ1bZb?installation=omnibus&release=15-3
#修改配置文件
[root@localhost ~]# vim /etc/gitlab/gitlab.rb
(...省略内容...)
external_url 'http://192.168.92.144' #将此处设为自己的ip地址亦或域名
(...省略内容...)
#重启服务生效配置(耐心等待)
[root@localhost ~]# gitlab-ctl reconfigure
(...执行结果省略...)
[root@localhost ~]# gitlab-ctl restart
[root@localhost ~]# gitlab-ctl restart
ok: run: alertmanager: (pid 23140) 1s
ok: run: gitaly: (pid 23150) 0s
ok: run: gitlab-exporter: (pid 23165) 0s
ok: run: gitlab-kas: (pid 23167) 1s
ok: run: gitlab-workhorse: (pid 23180) 0s
ok: run: logrotate: (pid 23197) 1s
ok: run: nginx: (pid 23203) 0s
ok: run: node-exporter: (pid 23211) 1s
ok: run: postgres-exporter: (pid 23218) 0s
ok: run: postgresql: (pid 23231) 0s
ok: run: prometheus: (pid 23245) 1s
ok: run: puma: (pid 23262) 1s
ok: run: redis: (pid 23267) 0s
ok: run: redis-exporter: (pid 23349) 1s
ok: run: sidekiq: (pid 23357) 0s
#查看gitlab的当前版本
[root@localhost ~]# head -1 /opt/gitlab/version-manifest.txt
gitlab-ce 15.3.3
#破解gitlab的管理员密码
[root@localhost ~]# gitlab-rails console -e production
--------------------------------------------------------------------------------
Ruby: ruby 2.7.5p203 (2021-11-24 revision f69aeb8314) [x86_64-linux]
GitLab: 15.3.3 (c629a47f87f) FOSS
GitLab Shell: 14.10.0
PostgreSQL: 13.6
------------------------------------------------------------[ booted in 29.16s ]
Loading production environment (Rails 6.1.6.1)
irb(main):001:0> user = User.where(id: 1).first #id为1的是超级管理员
=> #<User id:1 @root>
irb(main):002:0> user.password = '12345678' #密码必须至少8个字符
=> "12345678"
irb(main):003:0> user.save! #保存修改,若无问题将返回true
=> true
irb(main):004:0> exit #退出
#设置gitlab开机自启
[root@localhost ~]# echo "/usr/bin/gitlab-ctl start " >> /etc/rc.d/rc.local
[root@localhost ~]# chmod +x /etc/rc.d/rc.local
GitLab Web管理
Gitlab常用管理操作
- 项目管理(通常只是创建新项目)
- 创建成员组(针对某个项目创建一个成员组)
- 用户管理(此用户为Gitlab用户而非系统用户)
- 来了新员工,为其添加Gitlab用户
- 员工离职,将其Gitlab用户禁用或删除
在浏览器中使用gitlab服务器的ip访问,页面如下图所示。
登录进去的页面如下。这个警告信息是由于启用了“开放注册”。
管理页面如下
设置中文
操作步骤:点击右上角的头像==>Preferences==>Language==>简体中文==>Save changes,最后按F5键刷新生效。
上线项目流程
开发基线
- master(经过测试的没问题的基础代码)
- 20210512(新功能1)
- 20210513(新功能2)
发布–>发版–>上线(分支)
回滚、回退(防止上线时出问题,保证服务正常进行)
部署环境
- 开发环境
- 测试环境
- 预部署环境/准生产环境
- 生产环境(用户使用)
上线流程
定期变更(每周二、周四晚上18:30以后)
紧急变更,向CTO说明情况,由CTO来决定要不要发
- 开发代码(开发人员)———— 打回 ————|
- 测试(测试人员) ———— 有问题 ————|
- 发布(运维人员) ——> 预部署环境
- 测试(测试人员)
- 发邮件申请发布(开发人员)
邮件发给开发Leader、抄送给运维团队
- 填写变更单
- 开发Leader审批
- 评估影响范围(运维人员)
- 向运维Leader汇报(运维人员)
- 与开发Leader协商(运维Leader)
- 发布(运维人员) ——> 生产环境
- 测试(测试人员) ———— 出问题就回滚(运维人员) ————|