极狐 GitLab 小组代码仓库操作
2026/7/7 10:08:26 网站建设 项目流程

适合 3-5 人小组从零搭建极狐 GitLab 代码仓库、配置成员权限、规范分支协作,并处理常见问题。

1. 推荐总体方案

小组协作优先采用:

群组 Group └── 项目 Project / 仓库 Repository ├── main:稳定主干,受保护 ├── feature/xxx:功能分支 └── fix/xxx:修复分支

核心规则:

  1. 所有项目放在同一个小组群组下统一管理。
  2. 普通成员给 Developer,组长或技术负责人给 Maintainer,Owner 尽量只保留 1 人。
  3. main必须设为受保护分支,不允许直接 push。
  4. 所有人通过个人分支提交代码,再发起 MR,由 Maintainer 审核合并。
  5. 敏感信息、私钥、密码、数据库连接串不能提交到仓库。

2. 前置准备

所有成员先完成以下准备。

2.1 注册极狐 GitLab

  1. 访问https://jihulab.com
  2. 使用邮箱注册或按团队要求登录。
  3. 完成邮箱验证。
  4. 把自己的极狐用户名或注册邮箱发给管理员,方便邀请进群组。

2.2 安装 Git

下载地址:

https://git-scm.com/downloads

安装后验证:

git --version

2.3 配置 Git 用户信息

git config --global user.name "你的名字或极狐用户名" git config --global user.email "你的注册邮箱" git config --global --list

建议邮箱和极狐账号邮箱一致,方便提交记录关联到个人账号。

2.4 配置 SSH 密钥

生成密钥:

ssh-keygen -t ed25519 -C "你的邮箱"

查看公钥:

cat ~/.ssh/id_ed25519.pub

Windows 也可以直接打开:

C:\Users\你的用户名\.ssh\id_ed25519.pub

.pub文件里的全部内容复制到极狐 GitLab:

头像 -> 编辑个人资料/设置 -> SSH 密钥 -> 添加新密钥

验证:

ssh -T git@jihulab.com

看到欢迎信息即表示 SSH 可用。

注意:每个人、每台电脑都应该生成自己的 SSH 密钥。同一个账号可以添加多个公钥,不要共用别人的私钥。

3. 管理员创建群组

入口:

顶部导航 -> 群组 -> 新建群组 -> 创建群组

建议配置:

配置项建议
群组名称小组名或项目名,如team-demo
群组 URL英文小写、短横线,不用中文和空格
可见级别私有 Private

群组是团队权限和项目的容器。后续新建多个项目时,群组成员可以自动继承权限。

4. 创建项目仓库

入口:

进入群组 -> 新建项目 -> 创建空白项目

建议配置:

配置项建议
项目名称单项目可与群组同名,多项目用模块名
项目 URL默认即可
可见级别私有 Private
默认分支main
README 初始化见下方选择

README 是否勾选要分情况:

场景推荐
远程新仓库,本地还没有任何代码可以勾选 README
本地已经有完整代码,要推到极狐不要勾选 README,避免第一次 push 时历史冲突
从 GitHub/Gitee/其他仓库迁移优先用“导入项目”

5. 邀请成员和权限分配

5.1 群组层邀请,推荐用于内部成员

入口:

顶部导航 -> 群组 -> 进入小组群组 -> 左侧 成员/管理成员 -> 邀请成员

效果:

加入群组后,成员自动拥有群组下所有项目的对应权限。以后新增项目也会继承权限。

适用:

小组内部成员、长期参与项目的人。

5.2 项目层邀请,适合临时协作

入口:

进入具体项目 -> 左侧 项目信息/管理 -> 成员 -> 邀请成员

效果:

只对当前这个项目生效,不会获得群组下其他项目权限。

适用:

外包、跨部门协作、只看单个模块的人。

5.3 角色建议

角色权限建议人群
Owner删除群组/项目、管理所有权限仅组长或项目负责人 1 人
Maintainer合并 MR、保护分支、管理项目设置组长、技术负责人
Developer创建分支、推送个人分支、发起 MR普通组员
Reporter拉取代码、查看 Issue、评论测试、产品、只读成员
Guest通常不能看代码,只能看部分协作内容极少使用

权限叠加规则:如果一个人同时在群组和项目里被邀请,实际权限通常取更高角色。例如群组是 Developer,某项目单独给 Maintainer,则该项目里按 Maintainer 处理。

6. 本地代码接入方式

6.1 方式 A:全新项目,从远程克隆

适合管理员已在极狐建好空仓库或 README 仓库,组员拉取到本地开发。

cd ~/Projects git clone git@jihulab.com:群组名/项目名.git cd 项目名 git status

6.2 方式 B:本地全新代码,推送到空仓库

适合本地刚开始写代码,极狐项目是空的。

cd 你的项目目录 git init --initial-branch=main git remote add origin git@jihulab.com:群组名/项目名.git git add . git commit -m "feat: 初始化项目结构" git push -u origin main

6.3 方式 C:本地已有代码,上传到极狐

先确认是否已有旧 Git 历史:

git status git remote -v

如果本地本来就是一个 Git 仓库,且历史需要保留,不要直接删除.git。优先改远程地址:

git remote remove origin git remote add origin git@jihulab.com:群组名/项目名.git git push -u origin main

只有在明确不需要旧历史、只是想把当前文件作为新项目上传时,才考虑重新初始化:

git init --initial-branch=main git remote add origin git@jihulab.com:群组名/项目名.git git add . git commit -m "init: 上传现有项目代码" git push -u origin main

7. 标准开发流程

小组推荐简化分支模型:

main:稳定主干,受保护
feature/任务号-功能名:新功能
fix/任务号-问题名:修复 bug
hotfix/问题名:紧急修复

7.1 每次开发前同步主干

git checkout main git pull origin main

7.2 创建个人分支

git checkout -b feature/001-login-page

7.3 开发并提交

git status git add . git commit -m "feat: 完成登录页面表单逻辑"

提交信息建议:

前缀含义
feat:新功能
fix:修复 bug
docs:文档变更
style:格式调整,不影响逻辑
refactor:重构
test:测试相关
chore:构建、依赖、杂项维护

7.4 推送分支

第一次推送:

git push -u origin feature/001-login-page

后续推送:

git push

7.5 创建 MR

入口:

项目 -> 合并请求 -> 新建合并请求

配置:

选择
源分支自己的feature/xxxfix/xxx
目标分支main
标题简洁说明做了什么
描述写明改动内容、影响范围、测试方式
Reviewer/Assignee指派 Maintainer 或约定审核人

7.6 审核和合并

Maintainer 负责:

  1. 查看 Diff。
  2. 检查是否有无关文件、敏感信息、大文件。
  3. 确认代码能运行,必要时要求 CI 通过。
  4. 评论问题或要求修改。
  5. 无问题后合并。
  6. 合并后删除源分支。

7.7 合并后本地清理

git checkout main git pull origin main git branch -d feature/001-login-page

如果有权限,也可以删除远程分支:

git push origin --delete feature/001-login-page

8. 管理员必做保护配置

8.1 保护 main 分支

入口:

项目 -> 设置 -> 仓库 -> 受保护分支/保护分支

建议:

配置建议
分支main
允许推送No one / 无任何人
允许合并Maintainer 或 Owner
允许强制推送关闭
允许删除关闭

这样普通成员不能直接 push 到main,必须走 MR 审核。

8.2 合并请求规则

建议开启:

  1. 至少 1 人审核通过后才能合并。
  2. 有 CI 时,流水线通过后才能合并。
  3. 合并后自动删除源分支。
  4. 可选:合并前压缩提交。

8.3 推送规则

入口:

项目 -> 设置 -> 仓库 -> 推送规则

建议拦截:

  1. password
  2. secret
  3. api-key
  4. .env
  5. 私钥、证书、数据库连接串

推送规则不能替代人工检查,但可以挡住一部分低级事故。

8.4 CODEOWNERS,可选

项目根目录新建CODEOWNERS

# 所有改动默认由组长审核 * @组长极狐账号 # 前端文件由前端负责人审核 *.vue @前端负责人账号 *.js @前端负责人账号

适合多人维护不同模块的项目。

9. 可选 CI/CD 配置

项目根目录创建.gitlab-ci.yml

Node 项目示例:

stages: - lint - test - build lint: stage: lint image: node:20 script: - npm ci - npm run lint only: - merge_requests test: stage: test image: node:20 script: - npm ci - npm test only: - merge_requests - main build: stage: build image: node:20 script: - npm ci - npm run build artifacts: paths: - dist/ only: - main

自托管极狐 GitLab 可能需要管理员另外配置 GitLab Runner。

10. 常见问题和修正建议

10.1Permission denied (publickey)

排查:

ssh -T git@jihulab.com git remote -v

检查:

  1. 本地是否有id_ed25519id_ed25519.pub
  2. 公钥是否完整粘贴到当前极狐账号。
  3. 克隆地址是否是 SSH:git@jihulab.com:群组名/项目名.git
  4. 当前电脑是否使用了正确密钥。

说明:SSH 密钥后面的邮箱只是备注,不是认证核心。认证失败通常是公钥未添加、地址用错、密钥未被 SSH 客户端使用。

10.2 HTTPS 每次都要输密码

推荐改用 SSH。

如果必须用 HTTPS,优先使用 Git Credential Manager 或访问令牌,不建议长期使用明文保存:

git config --global credential.helper manager

credential.helper store会明文保存凭据,只有在明确接受风险时再用。

10.3 push 被拒绝:Updates were rejected

说明远程有本地没有的提交。

git pull origin main git push

如果当前在功能分支:

git checkout feature/xxx git fetch origin git merge origin/main git push

也可以用 rebase,但新手团队先统一用 merge 更稳。

10.4 合并冲突

git checkout feature/xxx git fetch origin git merge origin/main

打开冲突文件,处理:

<<<<<<< HEAD 你的代码 ======= 别人的代码 >>>>>>> origin/main

保留正确内容,删除冲突标记,然后:

git add . git commit git push

10.5 撤销已经 push 的提交

共享分支上优先用revert

git revert HEAD git push

注意:git revert不是“保留改动到工作区”,而是新建一个反向提交来撤销历史提交。它适合已经推送到远程、多人协作的场景。

如果提交还没 push,只是想撤回最近一次 commit 并保留文件改动:

git reset --soft HEAD~1

共享分支不要随便reset --hardpush -f

10.6 误提交敏感信息

第一时间处理:

  1. 立刻让相关密钥、密码、Token 失效并重新生成。
  2. 如果只是当前 MR,删除敏感内容并追加修复提交。
  3. 如果敏感信息已经进入主干历史,需要使用专门工具清理历史,并通知所有成员重新同步。

不要只删除文件就以为安全,因为 Git 历史里仍可能保留旧内容。

10.7 组员看不到仓库或克隆 403

管理员检查:

  1. 是否邀请到了正确账号。
  2. 是否在群组层或项目层给了权限。
  3. 角色是否至少 Developer。
  4. 项目是否在对应群组下。
  5. 项目可见级别是否为私有但成员未加入。

10.8 不要滥用删除.git

删除.git会丢失本地 Git 历史、分支、提交记录和远程配置。

只有在确认旧历史完全不需要时才删除。一般情况下,先用:

git remote -v git remote set-url origin git@jihulab.com:群组名/项目名.git

11. 小组硬性规范

权限规范

  1. 普通成员统一 Developer。
  2. 组长或技术负责人 Maintainer。
  3. Owner 尽量只保留项目负责人。
  4. 离职或退出项目的成员,从群组成员里移除。
  5. 临时外部人员,只在项目层邀请,并设置到期时间。

分支规范

  1. 禁止直接在main开发。
  2. 禁止直接 push 到main
  3. 分支名用英文、数字、短横线。
  4. 推荐格式:feature/任务号-功能名fix/任务号-问题名
  5. 合并前同步main,提前解决冲突。

MR 规范

  1. 一个 MR 只做一件事。
  2. MR 描述写明改了什么、为什么改、如何测试。
  3. 不要一次提交几十个无关文件。
  4. MR 必须审核后合并。
  5. 合并后删除源分支。

安全规范

  1. 不提交.env
  2. 不提交私钥、证书、密码、Token、数据库连接串。
  3. 大文件、安装包、视频等不要直接进 Git 仓库。
  4. 仓库默认保持私有。
  5. 重要项目定期导出备份。

12. 常用命令速查

# 查看状态 git status # 拉取 main 最新代码 git checkout main git pull origin main # 新建并切换分支 git checkout -b feature/xxx # 切换分支 git checkout main # 查看本地分支 git branch # 查看远程分支 git branch -r # 添加修改 git add . # 提交 git commit -m "feat: 描述本次改动" # 第一次推送新分支 git push -u origin feature/xxx # 后续推送 git push # 获取远程分支信息 git fetch origin # 切换到别人远程分支 git checkout -b feature/other-person-work origin/feature/other-person-work # 合并 main 到当前分支 git merge origin/main # 删除本地已合并分支 git branch -d feature/xxx # 删除远程分支 git push origin --delete feature/xxx # 撤销共享分支上的最近提交 git revert HEAD # 撤销本地未提交改动,慎用 git checkout -- .

13. 给组员的最短执行版

每天开发只记住这套流程:

git checkout main git pull origin main git checkout -b feature/任务号-功能名 # 写代码 git add . git commit -m "feat: 说明本次功能" git push -u origin feature/任务号-功能名

然后到极狐 GitLab 页面创建 MR:

源分支:自己的 feature/fix 分支
目标分支:main
指派审核人:组长或 Maintainer

审核通过合并后:

git checkout main git pull origin main git branch -d feature/任务号-功能名

需要专业的网站建设服务?

联系我们获取免费的网站建设咨询和方案报价,让我们帮助您实现业务目标

立即咨询