11-GitLab/Gitee 仓库搭建、权限分组、多角色团队协作流程大家好我是黒漂技术佬。前面两篇聊了版本管理今天回到源头——代码仓库本身。一个设计良好的仓库权限体系能让人流畅协作一个混乱的权限设计能让你的代码在某个周五下午被实习生意外推上生产环境。别问我是怎么知道的。一、选GitLab还是Gitee先给新手厘清概念GitLab开源的自建Git托管平台。可以部署在自己服务器上代码完全掌握在自己手里。社区版CE免费企业版EE付费但有更多安全功能。Gitee码云国内的Git托管平台类似GitHub。优势是访问速度快、中文界面、企业版功能相对便宜。我们的无人售货柜项目用的是自建GitLab。原因很简单硬件固件代码涉及设备安全证书放在公有云上过不了安全审计。二、仓库搭建基础流程GitLab上搭建一个项目仓库的步骤管理员登录点击New Project选择Create blank project填写Project name建议全小写用短横线分隔选择Visibility LevelPrivate/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技术LeaderMaintainer保护分支权限CR决策CTO/架构师Owner项目所有权只在少数关键项目四、Group与多项目统一管理当项目从1个变成10个后逐个设置权限会让人崩溃。Group就是用来解决这个问题的。创建GroupGroup: 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要求MRCI通过main/master完全保护无人Maintainer必须必须develop半保护无人Maintainer必须必须release/*保护无人Maintainer不强制必须feature/*不保护Developer任何人不强制不强制hotfix/*不保护DeveloperMaintainer不强制不强制关键点在于没有人可以直接push到main分支。任何代码进入main必须走MRCode ReviewCI通过。这不是不信任团队而是防止手滑。设置方式GitLabSettings → 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上创建MRMerge Request目标分支选develop填写MR模板描述改动内容、测试情况、截图至少一位同事CRApproveCI流水线自动跑编译、单测、代码扫描全部通过后自己点Merge我们有auto-merge功能但会保留人工确认七、企业实际配置示例这里分享我们团队的实际配置脚本通过GitLab API批量创建项目和权限# 批量创建Group子项目importgitlab glgitlab.Gitlab(https://gitlab.retail-cabinet.com,private_tokenxxx)groupgl.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})权限管理是团队的防火墙。一个清晰的权限体系不会限制创造力而是在有人不小心手滑或者机器中毒时确保你还有一份干净的代码可以回退。我是黒漂技术佬下回见。
