11-GitLab/Gitee 仓库搭建、权限分组、多角色团队协作流程
11-GitLab/Gitee 仓库搭建、权限分组、多角色团队协作流程
大家好，我是黒漂技术佬。前面两篇聊了版本管理，今天回到源头——代码仓库本身。一个设计良好的仓库权限体系，能让人流畅协作；一个混乱的权限设计，能让你的代码在某个周五下午被实习生意外推上生产环境。别问我是怎么知道的。
一、选GitLab还是Gitee
先给新手厘清概念：
- GitLab：开源的自建Git托管平台。可以部署在自己服务器上，代码完全掌握在自己手里。社区版（CE）免费，企业版（EE）付费但有更多安全功能。
- Gitee（码云）：国内的Git托管平台，类似GitHub。优势是访问速度快、中文界面、企业版功能相对便宜。
我们的无人售货柜项目用的是自建GitLab。原因很简单：硬件固件代码涉及设备安全证书，放在公有云上过不了安全审计。
二、仓库搭建基础流程
GitLab上搭建一个项目仓库的步骤：
- 管理员登录，点击"New Project"
- 选择"Create blank project"
- 填写Project name（建议全小写，用短横线分隔）
- 选择Visibility Level（Private/Internal/Public）
- 勾选"Initialize repository with a README"（建议勾上，帮团队快速了解项目）
- 创建完成后配置默认分支保护（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（所有者）
项目最高权限。能转让项目、删除仓库。通常只有技术负责人和管理员持有。
实际团队权限分配表：
| 角色 | 权限级别 | 说明 |
|---|---|---|
| 实习生 | Guest/Reporter | 看代码和文档，MR必须由导师review |
| 初级开发 | Developer | 开发分支操作，MR需approve |
| 高级开发 | Developer+ | 普通开发权限，但可以approve MR |
| 技术Leader | Maintainer | 保护分支权限，CR决策 |
| CTO/架构师 | 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 | 可Merge | 要求MR | CI通过 |
|---|---|---|---|---|---|
| main/master | 完全保护 | 无人 | Maintainer | 必须 | 必须 |
| develop | 半保护 | 无人 | Maintainer | 必须 | 必须 |
| release/* | 保护 | 无人 | Maintainer | 不强制 | 必须 |
| feature/* | 不保护 | Developer | 任何人 | 不强制 | 不强制 |
| hotfix/* | 不保护 | Developer | Maintainer | 不强制 | 不强制 |
关键点在于：没有人可以直接push到main分支。任何代码进入main必须走MR+Code Review+CI通过。这不是不信任团队，而是防止手滑。
设置方式（GitLab）：
Settings → Repository → Protected Branches → 选择main → Allowed to merge: Maintainers → Allowed to push: No one
六、团队协作日常流程
假设开发"扫码后推荐商品"功能：
- 从develop分支创建feature分支：
git checkout -b feature/recommend-product - 本地开发，完成编码，跑单测
- 推送到远程仓库：
git push origin feature/recommend-product - 在GitLab上创建MR（Merge Request），目标分支选develop
- 填写MR模板（描述改动内容、测试情况、截图）
- 至少一位同事CR+Approve
- CI流水线自动跑（编译、单测、代码扫描）
- 全部通过后自己点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})权限管理是团队的防火墙。一个清晰的权限体系不会限制创造力，而是在有人不小心手滑或者机器中毒时，确保你还有一份干净的代码可以回退。我是黒漂技术佬，下回见。