从零搭建到团队协作：手把手教你用GitLab搭建私有化代码仓库（含分支权限设置）
从零搭建到团队协作：手把手教你用GitLab搭建私有化代码仓库（含分支权限设置）
在当今快速迭代的软件开发环境中，代码管理工具的选择直接影响团队协作效率。对于中小型技术团队而言，自建代码仓库不仅能保障代码安全，更能根据团队特点定制协作流程。本文将带你从零开始，在Linux环境下完成GitLab私有化部署，并深入讲解如何配置符合团队协作规范的权限体系。
1. 环境准备与离线安装
1.1 系统依赖检查
在CentOS 7系统上部署GitLab前，需确保以下关键依赖已安装：
# 检查SSH服务状态 rpm -qa | grep openssh-server # 检查SELinux工具包 rpm -qa | grep policycoreutils-python若返回为空，则需要手动安装缺失组件：
sudo yum install -y openssh-server policycoreutils-python提示：生产环境建议保持防火墙开启状态，仅开放必要端口。提前规划好服务端口（如10005），避免与现有服务冲突。
1.2 离线包获取与安装
从清华大学镜像站获取最新版GitLab-CE安装包后，通过SCP上传至服务器：
scp gitlab-ce-16.9.2-ce.0.el7.x86_64.rpm user@server_ip:/opt/安装过程使用rpm命令并验证数字签名：
cd /opt sudo rpm -ivh --checksig gitlab-ce-*.rpm安装完成后，系统将自动创建以下目录结构：
/etc/gitlab：配置文件目录/var/opt/gitlab：应用数据目录/opt/gitlab：程序安装目录
2. 基础配置与网络调优
2.1 关键参数配置
编辑主配置文件时，建议设置以下核心参数：
# /etc/gitlab/gitlab.rb 关键配置项 external_url 'http://gitlab.example.com:10005' nginx['listen_port'] = 10005 gitlab_rails['initial_root_password'] = "临时密码" postgresql['shared_buffers'] = "256MB" # 根据内存调整配置生效后，执行重载命令：
sudo gitlab-ctl reconfigure2.2 防火墙与性能优化
针对生产环境，推荐采用精细化端口管理：
# 永久开放HTTP/SSH端口 sudo firewall-cmd --permanent --add-port=10005/tcp sudo firewall-cmd --permanent --add-service=ssh sudo firewall-cmd --reload对于资源受限的服务器，可调整Sidekiq并发数：
# 在gitlab.rb中增加 sidekiq['concurrency'] = 5 # 默认25，小内存机器需调低3. 用户体系与安全加固
3.1 多级权限架构设计
GitLab提供五种默认角色权限：
| 角色 | 代码推送 | 合并请求 | 分支保护 | 系统设置 |
|---|---|---|---|---|
| Guest | × | × | × | × |
| Reporter | × | √ | × | × |
| Developer | √ | √ | × | × |
| Maintainer | √ | √ | √ | × |
| Owner | √ | √ | √ | √ |
创建管理组的最佳实践：
# 使用RAILS控制台创建管理组 sudo gitlab-rails console Group.create!(name: 'Tech-Leads', path: 'tech-leads', visibility_level: 0)3.2 安全基线配置
必须关闭的风险功能：
- 注册功能：
Admin Area > Settings > General > Sign-up restrictions - 默认项目可见性设置为
Private - 开启强制2FA认证：
Admin Area > Settings > General > Sign-in restrictions
关键审计日志配置：
# 在gitlab.rb中启用 gitlab_rails['audit_events_enabled'] = true gitlab_rails['audit_log_format'] = 'json'4. 分支保护与协作流程
4.1 分支策略设计
典型的三分支模型配置示例：
main：受保护分支，仅允许合并请求release/*：预发布分支，允许开发者推送feature/*：功能开发分支，完全开放
设置分支保护规则：
# 通过API设置分支保护（需管理员权限） curl --request POST \ --header "PRIVATE-TOKEN: <your_access_token>" \ "https://gitlab.example.com/api/v4/projects/1/protected_branches?name=main&push_access_level=40&merge_access_level=40"4.2 合并请求规范
强制执行的代码审查策略：
- 至少2个批准才能合并
- 流水线必须成功
- 解决所有讨论线程
通过.gitlab/merge_request_templates/目录添加模板：
## 变更类型 - [ ] 功能新增 - [ ] Bug修复 - [ ] 重构优化 ## 影响范围 <!-- 描述改动影响的功能模块 --> ## 自测清单 - [ ] 单元测试通过 - [ ] 集成测试通过5. 持续集成实践
5.1 Runner配置指南
注册共享Runner的完整流程：
sudo gitlab-runner register \ --non-interactive \ --url "https://gitlab.example.com/" \ --registration-token "PROJECT_REGISTRATION_TOKEN" \ --executor "docker" \ --docker-image alpine:latest \ --description "Docker Runner" \ --tag-list "docker,linux" \ --run-untagged="false"5.2 流水线优化技巧
高效.gitlab-ci.yml配置示例：
stages: - test - build - deploy variables: MAVEN_OPTS: "-Dmaven.repo.local=.m2/repository" cache: paths: - .m2/repository - target/ unit-test: stage: test image: maven:3.8-openjdk-11 script: - mvn test artifacts: paths: - target/surefire-reports/6. 灾备与迁移方案
6.1 备份策略实施
全量备份命令及恢复测试：
# 创建备份（包含数据库和仓库） sudo gitlab-backup create # 模拟恢复流程 sudo gitlab-ctl stop unicorn sudo gitlab-ctl stop sidekiq sudo gitlab-rake gitlab:backup:restore BACKUP=备份编号6.2 跨版本升级路径
稳妥的升级路线图：
- 备份当前环境
- 在测试环境验证目标版本
- 分阶段升级（如13.12 → 14.0 → 14.9）
- 监控post-upgrade检查项
升级命令示例：
sudo rpm -Uvh gitlab-ce-16.9.2-ce.0.el7.x86_64.rpm sudo gitlab-ctl reconfigure sudo gitlab-rake db:migrate在实际运维中，我们发现配置/etc/gitlab/gitlab.rb时，将external_url设置为域名而非IP，可避免后续服务器IP变更带来的配置调整。对于50人以下的开发团队，将Sidekiq并发数控制在10以下，能有效避免内存溢出问题。