11-GitLab/Gitee 仓库搭建、权限分组、多角色团队协作流程

大家好，我是黒漂技术佬。前面两篇聊了版本管理，今天回到源头——代码仓库本身。一个设计良好的仓库权限体系，能让人流畅协作；一个混乱的权限设计，能让你的代码在某个周五下午被实习生意外推上生产环境。别问我是怎么知道的。

一、选GitLab还是Gitee

先给新手厘清概念：

• GitLab：开源的自建Git托管平台。可以部署在自己服务器上，代码完全掌握在自己手里。社区版（CE）免费，企业版（EE）付费但有更多安全功能。
• Gitee（码云）：国内的Git托管平台，类似GitHub。优势是访问速度快、中文界面、企业版功能相对便宜。

我们的无人售货柜项目用的是自建GitLab。原因很简单：硬件固件代码涉及设备安全证书，放在公有云上过不了安全审计。

二、仓库搭建基础流程

GitLab上搭建一个项目仓库的步骤：

1. 管理员登录，点击"New Project"
2. 选择"Create blank project"
3. 填写Project name（建议全小写，用短横线分隔）
4. 选择Visibility Level（Private/Internal/Public）
5. 勾选"Initialize repository with a README"（建议勾上，帮团队快速了解项目）
6. 创建完成后配置默认分支保护（Settings → Repository → Protected Branches）

命名规范建议：

项目全名: 无人售货柜-固件仓库 项目路径: retail-cabinet-firmware 说明: 无人售货柜安卓工控机固件开发与OTA配置

仓库多了之后没有命名规范就是一种折磨。我们团队约定：{业务域}-{系统}-{模块}，比如retail-cabinet-backend、retail-cabinet-firmware、retail-cabinet-miniapp。

三、权限模型详解

GitLab的权限模型是五级递进：Guest → Reporter → Developer → Maintainer → Owner。每一级包含上一级的所有权限。

Guest（访客）

最低权限。能看Issue但不能看代码。适合给外部合作方或甲方项目经理开放。

Reporter（报告者）

能看代码、提交Issue、查看CI/CD日志。不能推代码。适合测试工程师、产品经理，他们需要了解代码状态但不应该改代码。

Developer（开发者）

日常开发的核心角色。能推代码到非保护分支、创建和合并MR、管理Issue。不能推保护分支（关键！），不能改仓库设置。

Maintainer（维护者）

技术Leader的角色。能推到保护分支（这是我们非常小心使用的能力）、配置CI/CD、管理成员权限、设置分支保护规则。

Owner（所有者）

项目最高权限。能转让项目、删除仓库。通常只有技术负责人和管理员持有。

实际团队权限分配表：

四、Group与多项目统一管理

当项目从1个变成10个后，逐个设置权限会让人崩溃。Group就是用来解决这个问题的。

创建Group：

Group: retail-cabinet ├── backend (Java SpringBoot) ├── firmware (安卓固件) ├── miniapp (微信小程序) ├── admin-web (后台管理前端) ├── mcu (嵌入式MCU固件) └── common (公共库/Proto定义)

Group权限继承：

在Group级别设置成员权限后，所有子项目自动继承。比如把某位开发设为Group Developer，他就对这个Group下的所有6个仓库都有Developer权限。省去逐个仓库配置的麻烦。

子Group专项控制：

有时候需要细分权限。比如MCU固件工程师不应该修改后端Java代码。这时在特定子项目上覆盖权限即可：

Group retail-cabinet: Developer └── firmware: Maintainer (覆盖，嵌入式负责人)

五、保护分支（Protected Branches）配置

保护分支是整个版本管理体系的支柱。

标准配置：

关键点在于：没有人可以直接push到main分支。任何代码进入main必须走MR+Code Review+CI通过。这不是不信任团队，而是防止手滑。

设置方式（GitLab）：
Settings → Repository → Protected Branches → 选择main → Allowed to merge: Maintainers → Allowed to push: No one

六、团队协作日常流程

假设开发"扫码后推荐商品"功能：

1. 从develop分支创建feature分支：git checkout -b feature/recommend-product
2. 本地开发，完成编码，跑单测
3. 推送到远程仓库：git push origin feature/recommend-product
4. 在GitLab上创建MR（Merge Request），目标分支选develop
5. 填写MR模板（描述改动内容、测试情况、截图）
6. 至少一位同事CR+Approve
7. CI流水线自动跑（编译、单测、代码扫描）
8. 全部通过后自己点Merge（我们有auto-merge功能但会保留人工确认）

七、企业实际配置示例

这里分享我们团队的实际配置脚本，通过GitLab API批量创建项目和权限：

# 批量创建Group子项目importgitlab gl=gitlab.Gitlab('https://gitlab.retail-cabinet.com',private_token='xxx')group=gl.groups.get('retail-cabinet')projects=[{'name':'backend','description':'售货柜后端服务'},{'name':'firmware','description':'安卓工控固件'},{'name':'miniapp','description':'微信小程序'},{'name':'mcu','description':'嵌入式MCU固件'},]forprojinprojects:group.projects.create({'name':proj['name'],'description':proj['description'],'visibility':'private','initialize_with_readme':True})

权限管理是团队的防火墙。一个清晰的权限体系不会限制创造力，而是在有人不小心手滑或者机器中毒时，确保你还有一份干净的代码可以回退。我是黒漂技术佬，下回见。