在 CentOS 上，GitLab 的协作能力围绕项目、权限、代码评审、议题与 CI/CD 流水线展开，配合系统级网络与安全配置即可落地。
环境与基础配置
- 安装依赖与邮件服务：安装 curl、policycoreutils、openssh-server、postfix；启用并启动 sshd 与 postfix；在防火墙放行 HTTP/HTTPS/SSH（例如：firewall-cmd --permanent --add-service=http --add-service=https；firewall-cmd --reload）。
- 安装与初始化 GitLab：添加官方仓库后安装 gitlab-ce 或 gitlab-ee，在 /etc/gitlab/gitlab.rb 中设置 external_url（如：http://gitlab.example.com 或服务器 IP），执行 gitlab-ctl reconfigure 完成初始化。
- 访问与初始化：首次访问设置 root 密码，创建普通用户或开放注册，准备进入协作流程。
协作功能与落地步骤
- 创建项目与成员权限：新建项目（选择 Private/Internal/Public），在项目的 Members 中邀请成员并分配角色（如 Guest/Reporter/Developer/Maintainer/Owner），实现按角色的访问控制。
- 克隆与分支协作：使用 SSH/HTTPS 克隆仓库，采用 feature 分支 开发，保持提交粒度小且可描述；推送到远端后发起 Merge Request（合并请求） 进行代码评审。
- 代码评审与讨论：在 MR 中进行 评论/批注、请求变更、批准合并；通过 议题（Issues） 管理需求、缺陷与任务，关联 MR 与里程碑，形成闭环。
- 自动化工作流：在仓库根目录添加 .gitlab-ci.yml 定义构建、测试、部署流程；安装并注册 GitLab Runner 执行流水线，实现持续集成与持续交付。
典型协作流程示例
- 管理员或负责人在项目中添加成员并设定权限（如 Developer/Maintainer）。
- 开发者克隆仓库，基于 main/develop 创建 feature/x 分支并推送。
- 在 GitLab 上创建 Merge Request，指派评审人，关联 Issue 与 Milestone。
- 评审人审查代码、提出意见，开发者根据反馈迭代修改。
- 通过流水线自动运行测试，全部通过后由 Maintainer 合并到目标分支。
- 合并后自动触发部署（如到 staging），验证通过后发布到生产。
安全与网络配置要点
- 访问控制：仅开放必要端口（22/80/443），禁用匿名注册（如不需要），按“最小权限原则”分配成员角色。
- 身份认证：优先使用 SSH 密钥 而非密码进行 Git 操作，提升安全性与可审计性。
- 邮件通知：在 /etc/gitlab/gitlab.rb 中启用并配置 SMTP（如 smtp_address/smtp_port/smtp_user_name/smtp_password 等），确保 注册、MR/Issue 通知 正常送达。
- 公网协作与端口规划：若需对外协作，确保域名与证书正确；容器化部署时映射 80:80、2222:22，并在 Admin Area → Settings → General 设置 Custom Git clone URL for HTTP(S)，避免克隆地址显示内网端口。
性能与维护最佳实践
- 分支策略：采用 GitFlow/GitLab Flow，以 功能分支 + MR 为核心流程，保持主分支稳定。
- 大文件管理：使用 Git LFS 管理二进制与大文件，避免仓库膨胀与性能劣化。
- 权限与合规：细化 RBAC，对敏感分支设置保护策略与合并前审批。
- 维护与可靠性：定期 更新 GitLab 版本、执行 备份与恢复演练、监控实例健康状态，保障协作连续性。
