从零搭建GitLab完整指南：Git安装、Docker部署与IDEA集成实战

1. 项目背景与整体设计思路

1.1 为什么选择自建GitLab

Git这个工具，做开发的人基本绕不开。但很多时候你会发现，用Git和真正“玩明白Git”是两回事。我最初接触Git是在GitHub上托管开源项目，推几个仓库、提提PR，感觉也就那样了。直到后来公司内部要做一个私有项目，代码不能放外网，才开始认真琢磨自己搭一套Git托管服务。当时评估了几条路：直接用Gitee的私有仓库、买一台云服务器装Gitea、或者上GitLab。

Gitee私有仓库确实省事，但团队规模一大，权限控制、分支保护、Code Review流程这些功能都开始捉襟见肘。Gitea轻量归轻量，适合几个人小团队，可真要跑CI/CD、做容器镜像构建、搞自动化部署，能力还是弱了一些。GitLab则是一套比较完整的DevOps平台，不光管理代码，还把Issue跟踪、CI/CD、容器仓库全打通了。个人学习和搭建的成本虽然比另外两个高一些，但一次折腾清楚，后面受益很久。

这篇笔记我会完整记录从Git安装、GitLab服务器搭建、到IDEA日常集成使用的全过程，包括踩过的坑。如果你是刚接触Git的初级开发者，或者打算在团队内部搭一套代码托管平台，这篇文章可以直接帮你省掉一整个星期的摸索时间。

1.2 技术方案选型：Docker部署GitLab

搭建GitLab主要有两条路：一条直接在Linux服务器上装，另一条用Docker跑容器。我强烈建议用Docker，原因很实在：

• GitLab依赖的东西比较多，PostgreSQL、Redis、Nginx这些都是它内部的组件。直接装的话，这些组件要么由GitLab自带包管理，要么自己手动配，很容易把系统环境搞乱。
• 容器化之后，升级、备份、迁移都很方便。我后来从一台服务器迁到另一台，就一个docker-compose文件加一个数据卷拷贝搞定，要是传统安装方式，光搬数据库就够折腾半天。
• Docker部署时版本管理清晰，gitlab/gitlab-ce的镜像tag一拉，想换版本随时可以指定。

当然，Docker方式对服务器的要求并不低。GitLab本身挺吃内存的，官方推荐至少4GB内存，我实际用下来2GB内存跑起来也能用，但一旦开启CI Runner或者多人同时操作，卡顿会非常明显。我的建议是学习环境最少4GB，生产环境8GB起步。

另外，如果你用Docker Desktop在Windows/Mac上跑GitLab，注意Docker Desktop本身要占用不少资源，这时候宿主机建议16GB内存起步。我在Windows上用Docker Desktop部署过一次，性能不如Linux服务器的原生Docker，但作为本地学习和功能验证是够的。

1.3 整体学习路径设计

这次搭建的完整链路是这样的：先安装配置Git客户端，把Git的基本操作吃透；再在服务器上用Docker搭建GitLab，配置域名、SSH、HTTP克隆等核心功能；最后把IDEA和GitLab对接起来，覆盖日常开发的完整流程。

为什么按这个顺序？因为GitLab本质上就是一个Git远程仓库管理平台，如果你连Git的基本命令都不熟，就算把GitLab跑起来，后面用IDEA操作时出了问题也排查不了。我在实际教学中发现，很多人在IDEA里提交代码遇到报错就懵了，根本原因就是不清楚IDEA图形化按钮背后执行的是哪些Git命令。所以这篇笔记会先打牢Git基础，再去谈搭建和集成。

1.4 这套方案能解决什么问题

搭建完成之后，你会得到一个功能完整的私有代码托管平台，它解决的核心问题有三个：代码集中管理、团队协作权限控制、以及后续自动化流程的入口。

代码集中管理好理解，所有人都从GitLab拉取和推送代码，谁改了什么一目了然。权限控制方面，GitLab支持从项目到用户的细粒度权限设置，比如默认开发者权限只能推送自己分支、不能直接往main分支推，这个配合分支保护规则非常实用。自动化流程入口就更有价值了，GitLab自带的CI/CD功能可以做到代码推送后自动构建、自动测试、自动部署，这个我后面会专门聊到。

2. Git客户端安装与核心配置详解

2.1 Windows环境安装Git

Git在Windows上比较推荐的方式是直接下载官方安装包。打开git官网，选择对应Windows系统的64位版本下载，然后一路Next安装就行。但有几个关键的安装选项需要手动确认，它们直接影响后续使用体验。

第一个是“Adjusting your PATH environment”，这个要选“Git from the command line and also from 3rd-party software”。选这个选项后，Git会被加入系统PATH环境变量，这样你在CMD、PowerShell、IDEA终端里都能直接使用git命令。如果选了中间那个“仅从Git Bash使用”，那CMD和IDEA里调用git命令就会提示找不到命令。

第二个是“Choosing the default editor”，默认是Vim，对不熟悉Vim的人来说极其不友好，按了i才能输入，按Esc然后:wq才能退出。建议直接选“Use Visual Studio Code as Git's default editor”，前提是电脑装了VS Code。如果没有VS Code，也可以选Notepad++，核心目的就是让你在Git提交时能舒服地编辑提交信息。

第三个是“Adjusting the name of the initial branch in new repositories”，这里会问新仓库默认分支叫什么。现在GitHub和GitLab都默认用main，Git安装包的默认行为是“Let Git decide”（也就是master）。我建议自己改成main，因为这个分支名已经是业界默认习惯，避免后续在GitLab上创建仓库时分支名不一致导致混淆。

安装完成后，打开CMD或PowerShell，输入git --version，能输出版本号就说明安装成功了。

2.2 全局用户配置与SSH密钥生成

Git安装完第一件事，不是急着用，而是先把身份信息配置好。Git的每次提交都会记录作者信息，如果不配置，提交时会报错或者用系统默认值，非常容易出问题。

git config --global user.name "你的名字" git config --global user.email "你的邮箱"

这两个信息会写入当前用户目录下的.gitconfig文件。注意邮箱最好和你GitLab注册邮箱保持一致，这样提交记录才能正确对应到账号。

接下来是SSH密钥。用SSH协议克隆和推送代码的好处是：不用每次输入密码，安全性也更高。GitLab官方推荐ED25519算法，我生成命令如下：

ssh-keygen -t ed25519 -C "你的邮箱"

一路回车会生成两个文件：id_ed25519（私钥）和id_ed25519.pub（公钥）。私钥留在本地不要给任何人，公钥的内容之后要添加到GitLab账号里。Windows下公钥路径默认是C:\Users\用户名.ssh\id_ed25519.pub。

用下面的命令查看公钥内容：

cat ~/.ssh/id_ed25519.pub

2.3 Git常用命令场景速记

这一节是给基础薄弱的同学准备的。不要试图背命令，而是按场景来记，用多了自然就记住了。

场景一：初始化仓库并提交代码

git init # 当前目录初始化为Git仓库 git add . # 把所有改动的文件加入暂存区 git commit -m "首次提交" # 把暂存区内容提交到本地

场景二：关联远程仓库并推送

git remote add origin git@gitlab.example.com:group/project.git git branch -M main # 或master，取决于你远程仓库默认分支 git push -u origin main

场景三：日常开发流程

git pull # 拉取远程最新代码 git checkout -b feature/login # 新建并切换到功能分支 git add . && git commit -m "开发登录功能" git push -u origin feature/login # 推送当前分支到远程

场景四：解决冲突时的常用操作

git stash # 暂存未提交的改动，先拉取代码 git pull # 拉取最新代码 git stash pop # 恢复暂存的改动，可能需要手动合并

这里有个特别容易踩的坑：很多人习惯在IDEA里直接点“Update Project”，其实它底层执行的就是git pull。如果本地有未提交的改动，git pull可能会报错，最常见的错误是“Your local changes would be overwritten by merge”。这时候git stash出场，把本地改动暂存起来，拉取完代码再用git stash pop恢复，再手动解决冲突。

3. GitLab服务器搭建全流程实战

3.1 服务器准备与Docker环境部署

我在这一步选择了一台4核8G的Linux云服务器，系统用的CentOS 7.9。下面所有操作都需要root权限，如果你用普通用户，记得命令前加sudo。

先更新系统软件包：

yum update -y

然后安装Docker。不同系统安装方式不太一样，CentOS下推荐使用官方yum源安装：

yum install -y yum-utils yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo yum install -y docker-ce docker-ce-cli containerd.io systemctl start docker systemctl enable docker

安装完成后，验证一下：

docker --version docker ps

这里有个细节：如果是在国内服务器安装Docker，拉取镜像可能会很慢，需要配置镜像加速器。编辑/etc/docker/daemon.json文件，填上可靠的镜像加速地址，然后重启Docker：

systemctl daemon-reload systemctl restart docker

有了之前的经验，后来我用Docker Compose方式部署GitLab更顺手。安装Docker Compose插件：

yum install -y docker-compose-plugin

安装之后用docker compose version验证。

3.2 docker-compose部署GitLab

部署GitLab的关键是把配置写成docker-compose.yml文件，后续想改配置只用改这个文件再重启就行了。我在/opt/gitlab目录下创建了docker-compose.yml，内容如下：

version: '3.8' services: gitlab: image: 'gitlab/gitlab-ce:latest' container_name: gitlab restart: always hostname: 'gitlab.example.com' environment: GITLAB_OMNIBUS_CONFIG: | external_url 'http://gitlab.example.com' # 以下配置解决HTTP克隆的域名显示问题 nginx['listen_port'] = 80 ports: - '80:80' - '443:443' - '2222:22' volumes: - '/opt/gitlab/config:/etc/gitlab' - '/opt/gitlab/logs:/var/log/gitlab' - '/opt/gitlab/data:/var/opt/gitlab' shm_size: '256m'

几个重点：

端口映射：宿主机的2222映射到容器的22，是因为GitLab容器内部SSH默认走22端口，但宿主机22端口通常还被系统SSH占用。如果你确定了宿主机22端口没被占用，也可以直接写成'22:22'，否则建议用2222。后续SSH克隆地址就要写成git@gitlab.example.com:2222/group/project.git，这个细节很多人忽略。

数据目录：config、logs、data这三个目录一定要挂载出来，否则容器一旦删除重建，所有数据全没了。

shm_size：这个参数容易被忽视，GitLab的PostgreSQL需要共享内存，官方镜像建议设置256m，否则遇到某些并发场景会报共享内存不足。

配置好之后执行：

docker compose up -d

首次启动会比较慢，原因是镜像比较大（约2GB），加上GitLab内部组件初始化，可能要好几分钟。用日志跟踪进度：

docker logs -f gitlab

看到类似“gitlab Reconfigured!”的日志，就说明初始化完成了。

3.3 管理员账号与初始密码

GitLab初始管理员账号是root，初始密码存放在容器内的/etc/gitlab/initial_root_password文件中。24小时后这个文件会被自动删除，所以第一次登录前把密码记下来。

docker exec -it gitlab cat /etc/gitlab/initial_root_password

执行结果会显示类似这样的一行：

Password: xxxxxxxxxxxxxxxx

然后访问http://服务器IP，用root账号和这个初始密码登录。登录后第一件事就是修改密码。

我实际操作的时候遇到过一个问题：初始密码文件里包含一些特殊字符，比如单引号、斜杠，复制的时候容易漏掉后几位。建议直接复制整个密码串，不要手动敲。

3.4 配置域名解析与HTTP克隆地址优化

这一步是很多教程不会细讲的地方，也是最容易踩坑的。默认情况下，如果你用http://服务器IP这个地址登录GitLab，那么克隆项目时，GitLab生成的HTTP克隆地址也是http://服务器IP/group/project.git，这其实没问题。但如果你希望团队用公司域名访问，比如http://gitlab.example.com，那就必须把域名解析到服务器IP地址上。

域名解析分两步：

• 在DNS服务商后台添加一条A记录，把gitlab.example.com指向服务器公网IP。
• 在GitLab配置里把external_url改成http://gitlab.example.com。

同时，开发者的本机也要能解析这个域名。临时测试可以在本机hosts文件里加一行：

服务器公网IP gitlab.example.com

Windows下hosts文件路径是C:\Windows\System32\drivers\etc\hosts。

这个配置会影响后面IDEA从GitLab拉取代码时的地址。如果配置不对，GitLab页面显示克隆地址是“机器ID”而不是域名，克隆时就会报错。关于这个问题，后面常见问题章节我会再展开讲。

3.5 创建项目、用户与权限管理

进入GitLab主页后，先创建一个项目。有两种路径：空项目和导入项目。团队内部从零开始的话，直接选“Create blank project”，填项目名，选择可见性为Private（私有），这样外部人员看不到这个仓库。

创建好项目后，会跳转到一个页面，顶部显示克隆地址。这个时候仓库还是空的，可以用IDEA或者命令行把本地代码推上来。

用户管理方面，在“Admin Area”里添加用户，填写邮箱和姓名，系统会给用户发一封设置密码的邮件。如果内网没有邮件服务器，你可以在后台手动重置密码。

权限控制是最重要的部分。在项目设置里，找到“Settings -> Repository -> Protected branches”，默认情况下main分支是受保护的，只有Maintainer及以上角色才能直接推送。这样做的好处是防止有人直接往主干推代码，所有改动都必须走Merge Request流程。团队规不规范，很大程度上就靠这一条来控制。

3.6 配置SSH密钥到GitLab账号

SSH密钥的好处前面提过，这里说具体的操作路径：登录GitLab，点击右上角头像 -> Preferences（偏好设置） -> SSH Keys，把前面生成的id_ed25519.pub文件内容粘贴进去，点击“Add key”。

添加完成后，在本地验证一下是否连通：

ssh -T git@gitlab.example.com -p 2222

看到类似“Welcome to GitLab, @你的用户名!”的提示，就说明SSH配置成功了。这里如果改成其他端口，验证命令也要带上-p参数。另外，如果服务器上同时跑着系统SSH和GitLab的SSH，容易发生端口冲突，这也是为什么我把GitLab的SSH映射到2222的原因。

我还遇到过一种情况：服务器系统本身自带的SSH占用了22端口，GitLab容器内的SSH也监听22端口，但端口映射用的是2222，本地连接没任何问题，只是克隆地址里的端口号会变长。IDEA里SSH克隆地址写法是这样的：

ssh://git@gitlab.example.com:2222/group/project.git

如果用标准的git@gitlab.example.com:2222:group/project.git这种格式，某些Git客户端可能解析不对，特别是IDEA的GitLab插件，推荐统一用ssh://协议前缀格式。

4. IDEA集成GitLab完整配置

4.1 IDEA中配置Git路径

IDEA对Git的支持比较完善，但前提是它要能找到Git的安装位置。打开IDEA，进入“File -> Settings”，在左侧找到“Version Control -> Git”。如果IDEA自动识别到了Git安装路径，说明没问题；如果没有，手动点击右侧的文件夹图标，选择git.exe所在路径。

Windows下git.exe默认路径是C:\Program Files\Git\bin\git.exe。选好之后，点击“Test”按钮，如果能弹出版本号，说明Git路径配置成功。

这一步做完别忘了检查一个细节：“SSH executable”选项，建议从默认的“Built-in”改为“Native”。绝大部分同学遇到IDEA里SSH克隆失败，都是因为Built-in SSH客户端的密钥解析问题。改成Native以后，IDEA会直接调用系统ssh命令，密钥验证方式和命令行完全一致，成功率高很多。

4.2 IDEA连接GitLab仓库

配置好Git之后，接下来把GitLab账号信息填进去。打开“File -> Settings -> Version Control -> GitLab”，点击右侧“Add”按钮。

这里有两种登录方式：一种是直接用用户名密码登录，另一种是用Access Token。我特别说明一下Access Token的方式，因为它更安全，而且在账号做了两步验证时，密码登录会直接失败。

在GitLab页面，点击头像 -> Preferences -> Access Tokens，创建一个Personal Access Token。注意勾选api、read_repository、write_repository这几个权限范围。生成之后复制这个token（只显示一次，务必保存好），然后在IDEA的GitLab设置里粘贴。

如果之前是用密码方式登录后来失效了，报错“Login failed. check api token or gitlab version”之类的问题，八成是因为GitLab版本与IDEA内置的GitLab插件版本不匹配，或者Token权限不足。办法很直接：在IDEA的GitLab设置里把旧的服务器地址删掉，重新Add一次，用Token方式添加后重启IDEA。这个方法能解决90%以上的登录失败问题。

4.3 从GitLab拉取项目到IDEA

Clone远程项目是使用频率最高的操作。打开IDEA，如果首次进入IDEA，选择“Get from VCS”；如果已经在项目里，选“File -> New -> Project from Version Control”。

在弹出的窗口里，把GitLab项目页面上复制的克隆地址粘贴进来。这里分两种情况：

• SSH方式：地址形如ssh://git@gitlab.example.com:2222/group/project.git，优势是免密，推荐日常使用。
• HTTP方式：地址形如http://gitlab.example.com/group/project.git，首次操作会弹出登录框输入账号密码，但每次推送都要验证，而且如果仓库配了Token，用HTTP方式时还要在地址里带token，比较麻烦。

实际测试下来，IDEA里SSH克隆最稳妥的做法是先在命令行验证一次SSH连通，再切换回IDEA操作。因为IDEA的SSH认证其实也是调用了密钥文件，但它的日志不像命令行那样清晰。命令行能通了，IDEA基本就不会出问题。

4.4 日常开发流程：提交、推送、分支与Merge Request

项目开发中，IDEA的Git操作集中在右上方，或者在主菜单的“Git”入口。

日常提交推送的黄金流程是这样的：

1. 写代码前，先点一下“Git -> Pull”拉取远程最新代码，确保本地基于最新代码开发，避免写完才遇到冲突。
2. 编写代码后，在“Commit”窗口里勾选要提交的文件，写上简洁明了的提交信息，点击“Commit”按钮提交到本地。
3. 提交之前，IDEA会做一次代码检查，如果有错误或警告会有弹窗提示。这一步我建议不要直接跳过，检查一下代码规范性问题，省得推到GitLab上被Merge Request检查拦下来。
4. 确认无误后，点击“Push”按钮推送当前分支到远程。

分支操作方面，新建分支在IDEA右下角点击当前分支名，选择“New Branch”，输入分支名，然后进入开发。这是个非常好的习惯，日常开发都应该开分支，不要在main分支直接改代码。

推送分支到远程后，到GitLab项目页面会看到提示“Compare & create merge request”，点击创建一个Merge Request。填写描述，说明这次改了什么、为什么这么改，然后指派给评审人。评审通过后就可以合并了。这个流程走顺了，团队协作质量会明显提升。

4.5 IDEA中切换GitLab账号与清理凭据

换人、换账号或者Token过期后需要切换GitLab账号，这个操作不复杂但很多人找不到入口。

IDEA中账号信息通常存在系统凭据管理器里。Windows下打开“控制面板 -> 用户账户 -> 凭据管理器 -> Windows凭据”，找到gitlab.example.com相关的凭据项，展开后删除。下次再操作时，IDEA会重新弹出登录框，用新账号登录即可。如果使用的是Token方式，也可以直接在IDEA设置中“Version Control -> GitLab”里删除旧服务器的配置，再重新添加。

这里有个我在实际工作中遇到的高频问题：删除凭据后重新拉取代码，IDEA还是提示旧的账号权限不足。这时候光删除凭据不够，还要去“File -> Invalidate Caches / Restart”清理一下IDEA缓存，否则某些场景下IDEA会缓存旧的认证结果。

4.6 IDEA插件与Docker镜像构建的延伸

GitLab生态里还有一块在实际开发中非常有用：利用GitLab CI/CD自动构建Docker镜像。这和IDEA集成的相关点在于，很多团队并不直接在服务器上手动构建镜像，而是把代码推送到GitLab后，由CI Runner自动执行构建任务。

我后来为项目添加了一个简单的.gitlab-ci.yml文件，大概逻辑是这样的：

stages: - build - deploy build-image: stage: build image: docker:latest services: - docker:dind script: - docker build -t registry.example.com/myapp:$CI_COMMIT_SHA . - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD registry.example.com - docker push registry.example.com/myapp:$CI_COMMIT_SHA

这个文件放在仓库根目录，推送到GitLab后，如果有配置好的Runner，就会自动执行镜像构建和推送。团队开发者在IDEA里写完代码、推到GitLab，剩下的构建部署全部自动化，提交信息里带上commit SHA还能追溯到具体是哪个版本部署到生产环境。这个流程值得好好研究，但前提是把GitLab搭建好了。

5. 常见问题与排查技巧实录

5.1 “Login failed. check api token or gitlab version”解决实录

这条报错无论在IDEA还是其他Git GUI客户端里都出现过，网上搜索量很高。它的完整报错一般是：

Login failed. check api token or gitlab version. log in via git if the version of GitLab is too old

出现这个报错的几种原因：

原因一：GitLab版本过旧。旧版GitLab的API接口和当前IDEA插件不兼容，尤其是GitLab 13之前的版本，和新版IDEA的GitLab插件很容易出问题。解决办法是升级GitLab版本，用docker方式升级非常简单，只需要拉取新镜像并重启容器。

原因二：Personal Access Token的权限不够。如果Token创建时没勾选api权限，IDEA就没法调用GitLab的API接口。所以创建Token时，尽量把api、read_repository、write_repository这几个都选上。

原因三：IDEA的GitLab插件缓存了旧的认证信息。这个问题最隐蔽，现象是：账号密码明明是对的、Token也是新建的，但就是反复登录失败。解决方案是删除IDEA配置目录下的credentials文件，Windows下路径通常是C:\Users\用户名\AppData\Roaming\JetBrains\IntelliJIdea2023.1\options，删除后重启IDEA。删除之前建议备份，以免误删其他令牌信息。

根据我的实测，最常见的其实是原因三。GitLab版本不会天天变，Token权限一般也不会配错，但IDEA插件和服务器的认证状态缓存问题是老毛病。遇到登录失败，按照“删凭据 -> 重启IDEA -> 重新Token登录”的顺序排查，效率最高。

5.2 HTTP克隆显示机器ID而非域名的解决方案

GitLab安装后如果用IP地址访问，页面上显示的克隆地址是http://服务器IP/group/project.git，这算正常。但如果你配置了域名，页面还是显示机器ID（比如一串hostname），那GitLab的external_url配置就是不生效的。

我的排查思路供参考：

第一步，确认docker-compose里的external_url配置。如果直接用了IP，那克隆地址肯定是IP；如果想用域名，这里必须改成域名。

第二步，确认域名是否解析到了服务器。可以在本机命令行ping一下gitlab.example.com，如果ping通了就是解析正常。如果服务器有防火墙或者安全组限制，也要确保80端口是对外开放的。

第三步，确认GitLab是否重新加载了配置。修改external_url之后，需要执行：

docker exec -it gitlab gitlab-ctl reconfigure docker restart gitlab

reconfigure是GitLab用来重新生成Nginx配置和整体配置的命令，改过external_url之后必须要跑，否则Nginx仍然按旧配置在运行。

这三步做完，再去GitLab项目页面看克隆地址，就会正常显示域名了。同时注意，如果你在hosts里写了映射，那么本机通过域名访问时IDEA也能正常连接；其他同事访问还是得各自配hosts，或者走DNS。

5.3 升级GitLab版本时的高危漏洞修复

GitLab历史上出现过若干次安全漏洞，尤其是重大漏洞时官方会发安全公告，并要求尽快升级到修复版本。自建GitLab最怕的就是这一点：有人说“不升级就不会有事”，但安全问题这种事，风险极高，还是建议及时跟进。

我之前维护的一台GitLab版本比较旧，后来升级过程是这样的：先备份数据（非常重要），再把docker-compose里的镜像tag改为修复版本，然后执行docker compose pull和docker compose up -d。启动后跑一下reconfigure和migrate，确认版本号正常、仓库数据完整。

升级有个原则：不要跨大版本跳变，比如GitLab 15直接跳GitLab 17，这中间数据迁移可能有兼容性问题。稳妥的做法是一级级升：15到16，再16到17。每次升级前确认数据完整，项目、用户、提交记录都要抽查。

5.4 高频问题排查速查表

5.5 排查思路背后的方法论

排查这些Git和GitLab问题，我一直遵循一个原则：先用命令行复现，再用图形界面操作。原因很简单，命令行能给出完整的报错信息，而IDEA等GUI工具往往只给一个简短的提示，比如“Cannot run program”，你根本不知道底层是什么问题。

举个例子：IDEA推送失败提示“remote: HTTP Basic: Access denied”，看着很抽象。但你在命令行执行git push，它会明确告诉你用户名或密码错误。还有“Repository not found”这个报错，命令行会告诉你是因为权限不够还是仓库不存在，而IDEA只会笼统地弹出失败。

所以遇到问题不要慌，先切到命令行把同样的操作执行一遍，日志是最准确的排查依据。这会让你在实际操作中省下大量时间。

6. 实操心得与进阶建议

整套环境从零搭到日常使用顺畅，我先后花了一周多的时间，主要是卡在几个细节上：SSH端口的理解和配置、IDEA凭据缓存问题、还有域名配置不生效。这几个坑在文档里都写得很少，往往是出了问题才去搜，效率特别低。所以这篇文章里我把它们都列了出来，希望能帮后面的人少走弯路。

如果你是从零开始学，我的建议是：先在本地用Docker Desktop跑通一个最小实例，再去云服务器上部署。本地环境可以大胆折腾，大不了删掉重来；服务器上如果操作失误，影响的可能就是团队成员的日常使用了。

后续想要继续深入，可以考虑这几个方向：一是配置GitLab CI/CD，把自动构建、测试、部署这条流水线跑起来；二是使用GitLab的代码质量检查和安全扫描功能；三是结合Kubernetes搭建一套完整的容器化部署平台。GitLab并不是一个简单的代码托管工具，它更接近一个完整的DevOps平台，值得花时间研究。