GitLab:安装与使用详解
简介:GitLab是一个开源的代码版本控制与协作开发平台,提供包括持续集成/持续部署(CI/CD)、项目管理在内的全面功能。本指南深入介绍GitLab的安装过程,包括系统要求、依赖安装、Omnibus包获取、安装步骤及安全配置等。同时,全面展示GitLab的使用方法,如用户注册、项目创建、代码管理、CI/CD设置、权限管理、问题追踪等,并介绍GitLab的高级特性,如Runner配置、YAML语法、GitLab Pages以及API访问。通过本课程设计,读者将能全面掌握GitLab的安装和使用,以提高团队开发效率。 
1. GitLab的定义与功能介绍
GitLab是一款先进的、开源的代码仓库管理工具,它提供了代码托管、持续集成以及问题追踪等多种功能,从而简化了软件开发的流程。作为一个集成平台,GitLab集成了代码仓库管理、代码审查、问题跟踪、构建自动化以及持续部署等多种功能,几乎涵盖了软件开发生命周期的所有方面。它的强大功能和灵活性使得它成为许多开发团队的首选工具。接下来我们将具体分析其核心功能和使用优势。
2. 系统要求和安装依赖准备
2.1 硬件与软件的基本要求
2.1.1 推荐的服务器配置
在部署GitLab之前,服务器的配置是至关重要的一步。它需要一个平衡的硬件配置,以确保GitLab操作的稳定性和性能。根据GitLab官方的推荐,服务器应该具备以下配置:
- CPU :至少2个核心,推荐使用更高核心数的CPU以支持更多的并发操作。
- 内存 :至少4GB RAM,推荐至少8GB以运行较大的项目和处理更多的用户请求。
- 硬盘 :至少需要40GB存储空间,推荐使用SSD硬盘以获得更好的I/O性能。
此外,根据部署环境的不同,如单一服务器部署(All-in-one)或分层部署(Scaled-out),硬件要求也有所变化。在高负载的情况下,可能还需要增加CPU核心数、内存容量和增加存储空间。
2.1.2 支持的操作系统和环境
GitLab支持多种操作系统平台,包括但不限于:
- Ubuntu :18.04及以上版本。
- CentOS :7及以上版本。
- RHEL :7及以上版本。
- Debian :9及以上版本。
除此之外,还有一些其他的环境要求,例如必须安装有OpenSSL库、系统内核参数配置需符合GitLab推荐等。这些环境要求保证了GitLab能够在不同操作系统上运行,并确保了其运行时的稳定性和安全性。
2.2 安装依赖软件包
2.2.1 必要的依赖工具
在安装GitLab之前,需要安装一些必要的软件包和工具,包括但不限于:
- PostgreSQL :用于存储GitLab的数据库。
- Redis :用于提供缓存和队列服务。
- Nginx 或 Apache :作为Web服务器使用。
还需要确保操作系统中安装了以下软件包:
- curl 、 git 、 ca-certificates 、 openssl 、 policycoreutils-python-utils 等。
2.2.2 安装过程中的注意事项
在安装GitLab的过程中,有一些重要的注意事项需要遵循:
- 备份数据 :在安装过程中,始终确保备份了任何重要的数据。
- 网络配置 :确保服务器能够访问GitLab软件包仓库,并且服务器能够被用户网络访问。
- 配置文件设置 :正确配置GitLab的配置文件,如
gitlab.rb,根据文档进行必要的自定义。 - 防火墙和安全 :设置防火墙规则,并启用必要的安全功能,如SSH密钥认证。
以下是使用 apt 在Ubuntu系统上安装依赖软件包的示例代码块:
sudo apt update
sudo apt install -y curl openssh-server ca-certificates
sudo apt install -y postfix # GitLab推荐安装postfix用于发送邮件通知
# 安装用于数据库的软件包
sudo apt install -y postgresql postgresql-client libpq-dev
# 安装用于缓存和队列的软件包
sudo apt install -y redis-server
# 安装Web服务器Nginx
sudo apt install -y nginx
安装过程中的每一步都需要进行验证,以确保所有依赖都已正确安装。例如,可以通过检查软件包的版本来确认安装:
dpkg -s postgresql
如果输出显示已安装的软件包信息,那么说明PostgreSQL已经成功安装。同样的验证方法适用于其他软件包。
在安装依赖之后,系统应准备好进行GitLab的安装。请继续阅读下一章节,了解如何获取和安装GitLab的步骤。
3. 获取和安装GitLab的步骤
3.1 选择合适的GitLab版本
3.1.1 版本选择的依据
选择合适的GitLab版本是开始安装之前的第一步。对于初学者来说,了解版本选择的依据尤为重要。通常情况下,依据以下因素进行版本选择:
- 稳定性与功能性需求: 如果你需要一个稳定的环境进行日常的代码管理和协作,官方发布的稳定版本(通常带有
-ee后缀的版本号,比如13.1.5-ee)是你的最佳选择。如果你愿意尝试一些新特性并能够处理潜在的bug,你可以选择开发版本(通常带有-rc后缀的版本号,比如13.2.0-rc1)。 -
支持的生命周期: 官方提供长期支持版本(LTS),这些版本会得到更长时间的补丁更新和安全支持。对于生产环境,LTS版本是一个较为安全的选择。
-
依赖的兼容性: 选择一个版本时,要确保这个版本与你的操作系统和已安装的依赖软件包兼容。可以参考GitLab官方文档中关于依赖的兼容性部分。
-
社区与商业支持: 如果你的项目需要商业支持,那么选择企业版GitLab(GitLab EE)会提供专业的技术支持。社区版(GitLab CE)则完全免费,适合开源项目和小型团队。
3.1.2 官方与社区版本的对比
官方版本(GitLab EE)与社区版本(GitLab CE)之间有几个显著的区别:
-
功能差异: EE提供了额外的高级功能,如高可用性、高级审计日志、更多的用户管理工具等。而CE版本则包含了大多数项目管理和代码协作所需的基本功能。
-
支持与服务: 使用EE版本,你将获得企业级支持。而CE版本则依赖于社区提供的支持。
-
许可和成本: CE版本完全免费,基于开源许可证。EE版本则需要购买许可证,或者根据用户数量购买订阅服务。
在选择版本时,你应该根据你的组织规模、团队需求以及预算来做出明智的决定。
3.2 安装GitLab
3.2.1 使用脚本自动化安装
在安装GitLab时,自动化安装脚本是新手和有经验的用户都喜欢的选项,因为它极大地简化了整个过程。对于使用基于Linux系统的用户,可以使用以下步骤进行自动化安装:
-
获取安装脚本:
bash curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.deb.sh | sudo bash上述命令会从GitLab的官方仓库下载安装脚本,并通过bash执行。
-
安装GitLab企业版:
bash EXTERNAL_URL="http://gitlab.example.com" sudo apt-get install gitlab-ee在安装前,需要设置
EXTERNAL_URL环境变量,这里需要替换为你想要GitLab监听的URL。 -
完成安装与配置:
安装完成后,访问GitLab的
EXTERNAL_URL,初始的管理员密码会在安装过程中的日志中输出,使用该密码登录并更改密码,完成初始设置。
使用脚本自动化安装时,一定要确保脚本来源的可靠性,并且理解脚本执行的所有步骤,这样在出现问题时,你能快速定位并修复问题。
3.2.2 手动安装GitLab的步骤
手动安装GitLab虽然比自动化脚本繁琐,但能让你更好地理解GitLab的各个组件以及它们的配置方式。以下是手动安装GitLab的一般步骤:
-
准备操作系统: 确保操作系统是最新的,并且安装了所有必需的依赖包。
bash sudo apt-get update sudo apt-get upgrade -
安装依赖包: GitLab需要一系列依赖包,比如PostgreSQL数据库和Redis服务。
bash sudo apt-get install -y curl openssh-server ca-certificates \ sqlite3 libsqlite3-dev nodejs -
配置PostgreSQL和Redis: 安装完成后,你需要配置数据库和缓存服务。
bash sudo apt-get install -y postgresql postgresql-contrib sudo apt-get install -y redis-server接下来,你需要根据GitLab的官方文档设置数据库和创建用户,以及配置Redis服务。
-
下载并配置GitLab: 访问GitLab下载页面,下载相应的包,并根据官方文档配置它。
bash curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.deb.sh | sudo bash根据官方的指导,创建一个外部URL,并配置SSL证书和其他必要的设置。
-
启动并检查GitLab: 完成所有配置后,启动GitLab服务,并检查其状态。
bash sudo gitlab-ctl reconfigure sudo gitlab-ctl status
手动安装GitLab的过程虽然繁琐,但这种方式将教会你关于GitLab服务的许多细节,为后续的管理与优化打下坚实的基础。
4. GitLab Web界面安全设置
4.1 初次访问的安全配置
4.1.1 设置初始密码和管理员账号
首次访问GitLab的Web界面时,系统会要求你设置初始的密码和管理员账号。这是因为出于安全考虑,GitLab不允许你在未经设置管理员账户的情况下访问Web界面。初始密码必须包含一定数量的字符,并且需要有一定的复杂度,以防止暴力破解攻击。
在设置管理员账号时,你需要输入用户名、邮箱地址和初始密码。邮箱地址将用于发送通知和重置密码。完成这些步骤后,GitLab会提示你登录。确保保存好管理员账号和密码,因为如果忘记,需要重新配置整个GitLab实例。
4.1.2 启用SSL/TLS和设置HTTPS
为了确保数据在传输过程中的安全,建议在GitLab上启用SSL/TLS。启用SSL/TLS后,所有的Web界面访问都将通过HTTPS进行加密,保证用户数据的安全。GitLab可以使用自带的Let’s Encrypt证书或你自有的证书。
你可以通过GitLab的Web界面来启用SSL/TLS,或者通过编辑GitLab的配置文件进行设置。如果你选择通过配置文件进行设置,需要在 /etc/gitlab/gitlab.rb 文件中修改 external_url 来包含 https:// 协议,并确保指定了正确的SSL证书和密钥路径。
4.2 用户认证与授权
4.2.1 配置用户登录方式
GitLab支持多种用户认证方式,包括内部认证(如用户名和密码)、外部认证(如LDAP、OAuth等)。对于内部认证,GitLab使用自己的数据库来存储用户信息,这为管理员提供了完全的控制权。
如果你的组织使用LDAP或其他企业级认证系统,GitLab允许你将这些系统集成为用户认证源。这样,用户可以使用现有的公司凭证登录GitLab,这提高了用户体验,同时降低了管理额外账号的需要。
配置用户登录方式的步骤包括:
1. 访问GitLab的管理界面,在”Settings” -> “Authentication”中选择相应的认证方式。
2. 配置认证源的具体参数,如LDAP服务器地址、OAuth应用ID等。
3. 测试认证配置是否正常工作,并保存设置。
4.2.2 设置GitLab用户组和权限
在GitLab中,组是一组项目的容器,同时也是权限分配的单位。通过创建组,你可以将相关的项目集中管理,并且可以针对组设置统一的访问控制和权限。
例如,你可以创建一个名为“Developers”的组,并为该组配置成员。之后,可以为该组分配不同的权限级别,如“Guest”、“Reporter”、“Developer”或“Maintainer”,每个级别的权限都有明确的定义,控制着成员能做什么,不能做什么。
- 例如,”Guest”权限的用户只能读取项目信息,而”Maintainer”权限的用户则可以创建项目和管理成员。
设置用户组和权限的具体步骤如下:
1. 在Web界面的”Admin Area”中选择”Groups”菜单,然后点击”New Group”按钮。
2. 输入组的名称和描述,并选择需要的可见性级别。
3. 创建组之后,添加用户到组中,并为每个用户分配合适的权限级别。
4. 保存设置,并对组内的项目和设置进行管理。
通过这样细致的权限划分,GitLab可以有效地控制用户对项目资源的访问,并且确保信息安全。
4.3 配置与安全优化
4.3.1 审计日志和活动监控
审计日志是跟踪和记录用户活动的重要工具,有助于监控和调查潜在的安全事件。在GitLab中,可以开启审计日志功能来记录所有用户的活动,例如谁提交了代码、谁更改了系统设置等。
要开启GitLab的审计日志,需要在管理界面的“Settings” -> “Advanced settings”中启用相关选项。此外,还可以使用GitLab的API或导出功能将审计日志导出到外部系统进行长期存档和进一步分析。
4.3.2 安全配置最佳实践
最后,对于GitLab的Web界面安全配置,还有一些最佳实践需要遵循:
- 定期更新GitLab到最新版本,以获得最新的安全补丁和功能。
- 使用强密码策略,并定期更新密码。
- 启用两因素认证(2FA)提高账号安全性。
- 配置防火墙和入侵检测系统,监控可疑活动。
- 定期备份GitLab数据,确保可以快速恢复。
确保遵循这些最佳实践,可以大大减少安全风险,并且使GitLab运行更加稳定和安全。
以上内容详细地介绍了GitLab Web界面的安全设置,从初次访问的配置到用户认证与授权,再到安全配置的最佳实践。希望通过对这些方面的深入解析,你能掌握GitLab安全设置的关键要素,并根据实际情况进行优化和配置。
5. 用户注册与登录流程
5.1 用户注册
5.1.1 自注册的设置与限制
在GitLab中,自注册功能允许用户不需要管理员的介入即可自行注册成为系统的用户。这个功能对于开源项目来说非常有用,它允许全世界的贡献者轻松加入项目并提交代码。然而,这一功能也应根据组织的需求和安全策略来配置。
默认情况下,自注册可能是关闭的,管理员需要在Admin Area中启用它。自注册开启后,GitLab提供了一些限制措施,比如:
- 邮箱验证 :用户在注册时必须验证邮箱地址,这是为了确保注册人的身份真实性。
- 管理员批准 :管理员可以设置为用户自注册后需要等待管理员批准才能正式加入系统。
- 验证问题 :为了阻止机器人,可以设置一些简单的安全问题,注册时需要正确回答。
- IP限制 :可以对注册过程进行IP限制,以避免潜在的滥用。
启用自注册后,管理员还能利用各种自定义注册令牌(custom registration tokens),允许邀请用户以特定的角色加入项目。
5.1.2 注册时的安全措施
为了确保注册过程的安全性,GitLab提供了一些内置的安全措施:
- SSL/TLS :确保整个注册过程通过HTTPS传输,以防止数据被截取。
- 密码复杂度要求 :可以设置密码最小长度以及必须包含的字符类型,比如大小写字母、数字和特殊字符。
- 二次验证(2FA) :管理员可以要求所有用户在注册后启用二次验证,以提高账户安全。
- 防止数据泄露 :定期清理未验证或已弃用的账户,并监控异常的注册行为。
5.2 用户登录过程
5.2.1 支持的登录方式
GitLab支持多种登录方式,以方便用户和管理员登录系统:
- 用户名和密码 :最基础的登录方式,用户通过提供自己的用户名和密码进行登录。
- 外部认证服务 :GitLab可以与多种外部认证服务集成,如LDAP、SAML和OAuth,这对于已有成熟身份验证体系的企业尤为重要。
- 单点登录(SSO) :可以配置GitLab使用SSO,通过其他服务进行认证,以简化用户登录过程。
5.2.2 登录失败的处理策略
当用户在登录过程中遇到问题时,GitLab提供了一些策略来处理登录失败的情况:
- 密码重置 :如果用户忘记了密码,可以通过注册邮箱来重置密码。
- 二次验证(2FA)故障 :如果用户启用了二次验证但无法登录,可以使用预先设定的恢复代码或者通过备份方式恢复访问权限。
- 账户锁定 :为了防止暴力破解攻击,连续多次登录失败后,GitLab可以暂时锁定账户一段时间。
为了进一步增强登录过程的安全性,GitLab提供了密码策略和定期要求密码更改的功能,以确保系统的安全性不会因为旧密码的泄露而受到威胁。
## 表格:不同登录方式的对比
| 登录方式 | 优点 | 缺点 |
| ------------------- | -------------------------------------- | ------------------------------- |
| 用户名和密码 | 使用方便,适用于所有用户 | 容易受到密码猜测攻击 |
| LDAP | 单点登录,管理方便 | 对LDAP服务器的依赖性较高 |
| SAML | 提供统一身份管理 | 配置复杂,需要额外的身份提供商支持 |
| OAuth | 支持多平台登录,安全性较高 | 对第三方服务的依赖性强 |
graph TD
A[开始登录] --> B{用户选择登录方式}
B -->|用户名和密码| C[输入用户名和密码]
B -->|外部认证服务| D[通过外部服务认证]
B -->|单点登录(SSO)| E[通过SSO服务认证]
C -->|验证成功| F[登录成功]
D -->|验证成功| F
E -->|验证成功| F
C -->|验证失败| G[显示登录失败]
D -->|验证失败| G
E -->|验证失败| G
G --> H{处理登录失败}
H -->|密码重置| I[通过邮件重置密码]
H -->|二次验证故障| J[使用恢复代码或备份方式登录]
H -->|账户锁定| K[等待账户解锁]
# 示例代码:配置邮箱验证
# 在GitLab的配置文件中启用邮箱验证
echo "require_user_email_verification: true" >> /etc/gitlab/gitlab.rb
# 重新配置GitLab使设置生效
gitlab-ctl reconfigure
在上述代码示例中,我们通过编辑 /etc/gitlab/gitlab.rb 配置文件并设置 require_user_email_verification 为 true 来启用邮箱验证。随后,我们运行 gitlab-ctl reconfigure 来让新的设置生效。这是一个基础操作,但足以说明GitLab中安全性设置是如何通过简单的配置命令来完成的。
在管理GitLab用户注册和登录流程的过程中,理解和遵循最佳实践至关重要,这不仅涉及到用户体验,还关乎系统的安全性。通过适当的策略,您可以确保您的组织和项目的安全,同时为开发团队提供高效的工具以支持其开发工作。
6. 项目创建和代码仓库管理
随着版本控制系统的广泛使用,代码仓库管理已经成为开发者日常工作的核心部分。本章将深入探讨如何在GitLab中创建新项目以及如何进行高效的代码仓库管理。我们将从用户界面和命令行两个角度出发,全面了解项目创建的流程,以及后续的分支管理和合并请求等仓库操作。
6.1 创建新项目
创建项目是开始使用GitLab的第一步,无论是在Web界面还是通过命令行,GitLab都提供了直观易用的方式来初始化项目。
6.1.1 通过Web界面创建
在Web界面创建新项目是大多数用户的选择,因为它直观且易于理解。操作步骤如下:
- 登录GitLab账户后,点击界面上方的”+”按钮,选择“New project”(新建项目)。
- 在“Create a new project”页面上,你可以选择创建一个空项目,或者从模板、导入外部仓库或克隆已有项目中进行选择。
- 在“Project name”中填写项目的名称,它通常是项目标识的关键部分。
- 选择项目的可见性级别,可以是私有(Private)、内部(Internal)或公开(Public)。
- 你还可以选择初始化仓库时是否创建README文件、许可证文件等。
- 完成后,点击“Create project”按钮完成项目创建。
6.1.2 通过命令行初始化
对于喜欢使用命令行的用户,GitLab提供了通过CLI工具或使用 git 命令来初始化新项目的功能。
- 使用
git init命令在本地初始化一个新的Git仓库。 - 使用
git remote add命令将本地仓库与远程GitLab仓库关联。 - 使用
git push命令将本地的代码推送到GitLab上的远程仓库。
# 以下命令展示了通过git命令在GitLab上创建新项目的流程
$ git init my-new-project
$ cd my-new-project
$ git remote add origin https://gitlab.example.com/your-username/your-new-project.git
$ git add .
$ git commit -m 'Initial commit'
$ git push -u origin master
在执行上述命令之后,新的项目就被创建在了GitLab上,并且本地的更改也被推送到了远程仓库。
6.2 仓库管理操作
一旦项目创建完成,接下来就需要对代码仓库进行一系列的管理操作,包括分支管理、合并请求以及提交历史和标签管理。
6.2.1 分支管理和合并请求
分支是版本控制中的核心概念,通过分支可以实现功能的并行开发,合并请求则是分支管理中的关键操作。
- 分支管理:用户可以在Web界面上创建新分支,并进行切换查看分支状态。
- 合并请求:当一个分支的功能开发完成并测试无误后,可以通过Web界面发起合并请求(Merge Request,MR)到主分支。
- 在合并请求中,可以设置审查者(Reviewer)来对代码进行审查,确保代码质量符合要求。
- 合并请求可以通过点击“Merge”按钮合并到主分支,如果存在冲突,则需要开发者手动解决。
6.2.2 提交历史和标签管理
提交历史和标签管理是跟踪项目历史和版本发布的重要组成部分。
- 提交历史:用户可以查看每个分支的提交历史,理解每次提交的内容和差异。
- 标签管理:在项目开发到特定阶段需要标记时,可以创建标签(Tag)来标识稳定版本。
- 标签可以在Web界面中创建,并与发布说明相关联,方便用户了解每个版本的变更和特点。
GitLab的项目管理功能不仅仅限于创建和维护仓库,还包括了从持续集成(CI)到部署(CD)的完整DevOps流程,接下来的章节将深入讨论这些高级功能。
7. 持续集成/持续部署(CI/CD)的使用
7.1 CI/CD的基本概念
7.1.1 CI/CD的定义和作用
持续集成(Continuous Integration, CI)和持续部署(Continuous Deployment, CD)是现代软件开发中重要的实践方法,旨在快速集成代码更改并自动化发布到生产环境中。CI/CD提高了开发速度,降低了因集成问题而产生的风险,从而加快了新功能的上市时间并提高了软件质量。
- 持续集成 侧重于开发人员提交代码到共享仓库之后自动构建和测试的过程,目的是快速发现和定位问题。
- 持续部署 则是指软件的更新在通过自动化测试之后,自动部署到生产环境中的过程。
- 持续交付 是持续部署的变体,需要手动确认后才进行生产环境部署。
7.1.2 流水线的构建与优化
流水线(Pipeline)是CI/CD的核心,它定义了从代码提交到软件交付的整个流程。流水线通常包含以下几个阶段:
- 代码检出 :开发者提交代码到版本控制系统。
- 构建 :自动化编译应用和依赖。
- 测试 :执行单元测试、集成测试、性能测试等。
- 部署 :将构建好的应用部署到测试或生产环境。
- 验证 :自动化测试确认部署的应用达到预期。
- 反馈 :将测试结果和部署状态反馈给相关开发人员和团队。
构建和优化流水线需要考虑以下几个方面:
- 流水线的快速反馈 :需要确保任何代码提交后,快速得到反馈。
- 并行处理 :某些阶段可以并行化以缩短整体时间。
- 依赖管理 :确保环境一致性和减少构建时间。
- 可维护性 :流水线代码需要清晰、简单,以便维护和扩展。
7.2 配置和管理CI/CD流程
7.2.1 .gitlab-ci.yml文件的编写
在GitLab中,使用 .gitlab-ci.yml 文件配置CI/CD流程。这个文件应放在项目的根目录下,并定义了流水线的各个阶段和作业(job)。以下是一个基本的配置示例:
stages:
- build
- test
- deploy
build_job:
stage: build
script:
- echo "Building the project"
- make build
tags:
- docker
test_job:
stage: test
script:
- echo "Running tests"
- make test
deploy_job:
stage: deploy
script:
- echo "Deploying the project"
only:
- master
stages定义了流水线包含的阶段。- 每个作业 (
job) 都指定了它属于哪个阶段,并通过script指令定义要执行的命令。 tags用来选择合适的运行器(Runner),在这个例子中选择一个标记为docker的运行器。only指令用于限制作业在特定分支上运行,例如这里的deploy_job仅在master分支上执行。
7.2.2 环境变量和触发规则的设置
环境变量可以在 .gitlab-ci.yml 文件中设置,也可以在GitLab的CI/CD设置界面中进行配置。它们为流水线提供了灵活的配置方式。例如:
variables:
DATABASE_URL: "postgres://user:password@postgres:5432/db"
触发规则(triggers)定义了什么时候会触发作业执行,例如可以通过API触发,或者在代码库有更新时自动触发。
deploy_job:
only:
- master
when: manual
在上面的例子中, deploy_job 被设置为需要手动触发( when: manual ),允许团队成员决定何时部署到生产环境。
通过这些配置和管理的实践,GitLab CI/CD允许团队以自动化的方式持续集成和部署代码变更,提高开发流程的效率和可靠性。
简介:GitLab是一个开源的代码版本控制与协作开发平台,提供包括持续集成/持续部署(CI/CD)、项目管理在内的全面功能。本指南深入介绍GitLab的安装过程,包括系统要求、依赖安装、Omnibus包获取、安装步骤及安全配置等。同时,全面展示GitLab的使用方法,如用户注册、项目创建、代码管理、CI/CD设置、权限管理、问题追踪等,并介绍GitLab的高级特性,如Runner配置、YAML语法、GitLab Pages以及API访问。通过本课程设计,读者将能全面掌握GitLab的安装和使用,以提高团队开发效率。
更多推荐




所有评论(0)