GitCode怎么添加组织和管理（详细教程）

GitCode 项目、组织与多方协同操作手册

文档用途：用于团队内部落地 GitCode 的项目创建、组织管理、成员权限配置、源码协作和多方协同。

说明：本文基于 2026-04-08 查阅 GitCode 官方帮助文档整理，界面名称和入口可能随平台版本调整而变化；如实际页面有微调，请以 GitCode 当前页面为准。

1. 适用场景

本文适合以下场景：

• 新团队第一次在 GitCode 上建立代码协作环境
• 已有团队准备把代码仓库从个人名下转到组织名下统一管理
• 需要对成员权限、项目访问和协作流程做规范化治理
• 需要多人并行开发、代码评审、任务看板和流水线配合
• 需要与外部合作方、测试人员、维护者共同协作

---

2. GitCode 中几个关键概念

在开始之前，先统一几个概念：

2.1 个人项目

适合：

• 个人练习
• 临时验证
• 尚未形成团队协作的小项目

特点：

• 权限由项目所有者单独管理
• 不适合长期多人协作治理
• 不适合企业级、部门级统一权限管理

2.2 组织

适合：

• 企业团队
• 开源社区
• 研发小组
• 学术团队

特点：

• 可以统一管理多个项目
• 可以统一管理成员、角色、权限和协作流程
• 可以配合 Issue、PR、看板、讨论、流水线等做协同

2.3 项目

GitCode 中项目是代码协作的核心单元。一个组织下面可以有多个项目。

项目内通常会承载：

• 源代码
• README、设计文档、接口文档
• Issue
• Pull Request
• 分支
• Tag / Release
• Wiki
• 流水线配置

2.4 仓库类型

GitCode 当前支持：

• 代码仓：用于普通软件开发
• 模型仓：用于 AI/ML 模型文件管理
• 数据集仓：用于数据集管理

如果你要做常规软件开发，通常选择"代码仓"。

---

3. 推荐的整体落地顺序

建议不要一上来就直接建仓库并拉人开发，推荐按下面顺序实施：

1. 注册账号并完成基础安全设置
2. 建立组织
3. 配置组织基础信息和默认规则
4. 在组织下创建项目
5. 确定项目权限模式
6. 邀请成员并分配角色
7. 配置分支保护和 PR 规则
8. 配置 Issue / PR 模板、标签、里程碑、看板
9. 成员通过 SSH 或 HTTPS 克隆代码
10. 按分支开发 + PR 评审 + 流水线校验方式协作
11. 合并、发布、归档和审计

---

4. 前置准备

4.1 账号准备

每位成员都应拥有独立的 GitCode 账号，不要共用账号。

建议：

• 使用实名或可识别昵称
• 绑定企业邮箱
• 开启个人安全配置
• 每台设备使用独立 SSH Key

4.2 本地 Git 基础配置

在本地电脑先完成 Git 身份配置：

git config --global user.name "你的姓名或团队统一昵称"
git config --global user.email "你的邮箱地址"

建议团队统一格式：

• user.name 使用真实姓名或统一工号格式
• user.email 使用企业邮箱，便于审计和追踪

4.3 SSH Key 配置

GitCode 官方文档建议优先使用 ED25519 类型 SSH Key。

生成方式：

ssh-keygen -t ed25519 -C "your_email@example.com"

如果需要兼容旧环境，也可使用 RSA 4096：

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

生成后，在 GitCode 中进入：

个人设置 -> 安全设置 -> SSH 公钥 -> + SSH 公钥

再把公钥内容粘贴进去保存。

建议：

• 一台电脑一个 SSH Key
• 离职、设备丢失、设备更换时及时清理对应密钥
• 不要把私钥发给任何人

---

5. 如何创建组织

5.1 什么时候应该先建组织

只要符合以下任一情况，就建议优先建组织，而不是直接建个人项目：

• 项目不止 1 个人维护
• 需要多人持续协作
• 需要角色分工和权限控制
• 需要统一管理多个仓库
• 需要未来扩展到测试、运维、产品、外部合作方一起参与

5.2 创建组织详细流程

GitCode 官方当前操作入口为：

1. 进入 GitCode
2. 打开"组织管理"页面
3. 点击"新建组织"
4. 填写组织基本信息
5. 点击"创建组织"

建议在创建时明确以下信息：

• 组织名称：建议使用团队名、部门名、公司名或项目群组名
• 组织路径：建议简短、稳定，避免后期频繁修改
• 组织简介：写清楚组织用途，例如"嵌入式研发团队""数据平台组""无人机控制项目组"
• 可见性：开源团队可考虑公开；企业研发建议默认私密

5.3 组织创建后第一时间要做的事情

组织创建完成后，不建议立刻开始开发，先完成基础治理：

1. 补全组织简介、Logo、联系邮箱、官网等信息
2. 明确组织是公开还是私密
3. 确认组织内项目采用什么权限模式
4. 配置组织默认设置
5. 预定义项目标签、PR 规则、是否需要 CLA、WebHook

5.4 组织里通常做什么

组织主页通常会承载这些能力：

• 项目管理：创建和导入项目
• 成员管理：管理角色、访问权限、成员活动
• 团队协作：Issue、Pull Request、看板、讨论
• 组织设置：基础信息、集成服务、资源管理

---

6. 如何创建项目

6.1 创建项目的常见方式

GitCode 当前支持三种常见方式：

• 新建空白项目
• 通过模板项目创建
• 导入或迁移现有项目

6.2 新建项目详细流程

GitCode 官方当前入口为：

1. 在任意页面顶部点击 + 新建
2. 选择"新建项目"
3. 选择项目归属：个人账号或组织
4. 选择仓库类型：代码仓 / 模型仓 / 数据集仓
5. 设置项目可见性：公开或私密
6. 按需勾选初始化内容：README.md、.gitignore、LICENSE
7. 点击"创建项目"

6.3 创建项目时的关键选择

1. 项目归属

建议：

• 团队项目统一创建在"组织"下
• 个人实验项目才放个人名下

原因：

• 组织下便于统一权限和人员变动管理
• 避免人员离开后仓库仍挂在个人账号名下

2. 项目可见性

建议：

• 企业、客户、商业项目默认私密
• 开源项目才设为公开

注意：

• GitCode 官方说明，公开项目的代码、Issue、Wiki 等内容都可能被访问
• 建项目前必须确认没有凭据、私钥、内部地址、客户数据等敏感信息

3. 初始化选项

建议：

• README.md：建议勾选
• .gitignore：建议勾选
• LICENSE：开源项目必须认真选择；闭源项目可按公司规范处理

6.4 通过模板项目创建

如果你们有统一项目骨架，建议使用模板项目。

适用场景：

• 每个新项目都要带相同目录结构
• 每个新项目都要带统一的 README、CI 配置、模板文件
• 多个团队需要快速复制标准工程结构

GitCode 当前说明：

• 模板项目可在"项目设置 -> 基础设置"中标记为模板项目
• 新建项目时可选择模板项目进行初始化
• 新项目会带模板文件和一个初始化提交
• 不会带历史提交记录

6.5 导入项目

如果已有外部仓库，可以通过 URL 导入：

1. 点击 + 新建
2. 选择"导入项目"
3. 输入 Git URL
4. 选择项目归属
5. 配置名称、路径、公开性等选项
6. 等待导入完成

注意：

• URL 必须可用，并且通常以 .git 结尾
• 如果源项目是私有仓库，需要提供访问凭证

6.6 迁移项目

如果仓库来自 GitHub、Gitee、GitLab，可使用平台迁移能力。

当前官方说明中的关键点：

• GitCode 支持从 GitHub、Gitee、GitLab 迁移仓库
• 需要源平台的个人访问令牌（PAT）
• 当前迁移主要支持 Git 仓库本身
• Wiki / Issue / PR / Release 暂不支持随仓库一起迁移

因此，迁移后建议补做：

• 重新建立 Issue 模板
• 补建里程碑
• 补建 PR 模板
• 补建标签
• 补建流水线和保护分支规则

---

7. 组织项目的权限模式怎么选

GitCode 官方说明，组织项目通常有两种权限模式：

• 继承模式
• 独立模式

7.1 继承模式

含义：

• 项目直接继承组织中的成员和权限
• 权限统一由组织管理员管理

适合：

• 团队成员高度稳定
• 一个组织内多个项目成员基本相同
• 希望减少重复加人、重复配权限的工作

7.2 独立模式

含义：

• 项目独立管理成员和权限
• 与个人项目权限管理方式类似

适合：

• 某些项目只允许组织内部分成员参与
• 某些项目涉及保密模块或客户定制模块
• 同一组织内项目之间权限差异很大

7.3 推荐选择

可以按下面规则判断：

• 团队统一研发仓：优先选"继承模式"
• 保密项目、客户项目、专项项目：优先选"独立模式"
• 刚开始不确定时：先用"继承模式"，对少数特殊项目再改成"独立模式"

---

8. 成员角色和常见人员管理方式

8.1 GitCode 常见系统角色

GitCode 官方给出的常见系统角色如下：

角色	典型职责	建议给谁
Owner（管理员）	拥有全部权限和最终决策权	组织负责人、平台管理员
Maintainer（维护者）	负责日常维护、处理 PR、发布等	技术负责人、仓库负责人
Developer（开发者）	编写和提交代码，参与开发和讨论	普通研发成员
Reporter（参与者）	报告问题、提供反馈、参与讨论	测试、产品、需求提出方
Guest（浏览者）	以浏览和有限讨论为主	外部观察者、只读协作者

8.2 角色分配建议

建议不要把 Owner 发得太多。

推荐做法：

• 每个组织保留 1 到 2 个 Owner
• 每个项目配置 1 到 3 个 Maintainer
• 大部分研发人员使用 Developer
• 产品、测试、实施同事多数使用 Reporter
• 临时外部合作方优先从 Guest 或 Reporter 起步

8.3 成员管理的常见规则

GitCode 官方文档中有两个重要限制：

• 只有管理员和维护者可以进行成员管理
• 项目创建者默认为管理员，且不能被移除

8.4 如何邀请组织成员

组织层面通常有两种加入方式：

方式一：按用户名或邮箱邀请

流程：

1. 进入组织
2. 打开"组织成员"
3. 点击"邀请成员"
4. 输入用户名或邮箱
5. 选择角色
6. 发送邀请

方式二：通过邀请链接加入

流程：

1. 进入组织成员管理
2. 点击"邀请链接"
3. 选择角色
4. 设置失效时间
5. 填写备注
6. 创建后复制链接给受邀人

注意：

• 邀请链接在有效期内可能被重复使用
• 邀请链接不要随意发到公开群
• 建议设置较短失效时间

8.5 如何邀请项目成员

项目层面也有两种常见方式：

方式一：通过链接邀请

流程：

1. 进入项目
2. 进入"项目成员管理"
3. 点击"邀请链接"
4. 设置默认角色和有效期
5. 创建后复制链接给受邀人

方式二：通过用户名或邮箱邀请

流程：

1. 进入项目
2. 进入"项目成员管理"
3. 点击"邀请成员"
4. 输入用户名或邮箱
5. 选择角色
6. 发送邀请

8.6 如何修改成员角色

项目中需要提权、降权时：

1. 进入"项目成员管理"
2. 点击成员当前角色
3. 在下拉框中选择新角色
4. 保存

常见场景：

• 新人试用期先给 Reporter，熟悉后改为 Developer
• 模块负责人从 Developer 提升为 Maintainer
• 外部合作结束后从 Developer 降到 Guest 或直接移除

8.7 如何移除成员

流程：

1. 进入组织或项目的成员管理页面
2. 找到对应成员
3. 点击移除
4. 确认

建议在人员离开或合作结束时同步做以下动作：

• 立即移除组织成员身份
• 立即移除项目成员身份
• 撤销未使用的邀请链接
• 审查该成员名下未处理的 Issue、PR、里程碑和看板任务
• 审查是否还有本地部署密钥、Webhook Token、第三方系统联动凭据

上一条中的 Token、部署密钥、第三方联动凭据属于团队治理建议，不是单一 GitCode 页面按钮动作，但在实际离岗交接中很重要。

8.8 自定义角色怎么用

GitCode 组织支持自定义角色。

适合场景：

• 需要"测试负责人""发布管理员""只允许合并 PR 的角色"
• 需要把权限细到某些项目、PR、分支、标签、里程碑、看板操作

当前官方说明中的关键点：

• 自定义角色在"组织设置 -> 角色与权限"中创建
• 每个组织最多可创建 50 个自定义角色
• 角色名称必须唯一，且不能与系统角色重名
• 组织和项目成员管理权限不支持随意自定义开放
• 如果项目设置了保护分支，最终仍以保护分支规则为准

建议：

• 先用系统角色跑通流程
• 真有管理边界需求时再引入自定义角色
• 自定义角色数量不要过多，否则后期审计和维护会很乱

---

9. 新成员加入后，怎么管理源代码

成员加入项目后，不是"能看到仓库"就算完成，建议按下面流程做入项。

9.1 入项标准流程

1. 接收组织或项目邀请
2. 完成 GitCode 账号安全设置
3. 配置本地 Git 用户名和邮箱
4. 配置 SSH Key
5. 克隆仓库到本地
6. 创建自己的开发分支
7. 在分支上开发、提交、推送
8. 通过 PR 合入目标分支

9.2 克隆代码

git clone <项目地址>
cd <项目目录>

建议优先使用 SSH 地址，减少反复输入凭据。

9.3 创建开发分支

不要直接在 main 或 master 上开发。

建议使用：

git switch -c feature/xxx

或：

git checkout -b feature/xxx

推荐分支命名：

• feature/功能名
• bugfix/问题名
• hotfix/紧急修复名
• release/版本号
• docs/文档主题

9.4 提交代码

示例：

git add .
git commit -m "feat: 增加串口重连机制"
git push origin feature/serial-reconnect

建议统一提交信息格式：

• feat: 新功能
• fix: 缺陷修复
• docs: 文档修改
• refactor: 重构
• test: 测试相关
• chore: 杂项调整

9.5 为什么不要直接推主分支

推荐所有成员都遵守以下原则：

• 不直接向主分支推送
• 所有功能改动通过分支开发
• 所有合并通过 PR 完成
• 所有重要改动至少经过 1 人评审

原因：

• 便于追溯
• 便于讨论
• 便于回滚
• 便于流水线自动检查
• 便于多人并行开发

9.6 常用命令行速查

说明：下面是成员日常最常用的 Git 命令。若项目默认分支不是 main 而是 master，请把命令中的 main 替换为 master。

9.6.1 查看当前仓库状态

git status
git branch
git branch -a
git remote -v

适用场景：

• 查看当前在哪个分支
• 查看有哪些本地和远程分支
• 查看远程仓库地址是否配置正确

9.6.2 首次从 GitCode 克隆仓库

git clone <SSH或HTTPS仓库地址>
cd <项目目录>
git branch -a

9.6.3 本地已有项目，首次上传到 GitCode

如果代码原本就在本地，还没有推到 GitCode，可按下面操作：

cd <你的项目目录>
git init
git add .
git commit -m "feat: initial commit"
git branch -M main
git remote add origin <GitCode仓库地址>
git push -u origin main

说明：

• git branch -M main 用于把当前主分支统一命名为 main
• git push -u 会建立本地分支和远程分支的跟踪关系

9.6.4 开发前先同步主分支最新代码

git fetch origin
git switch main
git pull origin main

如果你还没有 main 本地分支，可先执行：

git checkout -b main origin/main

9.6.5 从主分支创建功能分支

git fetch origin
git switch main
git pull origin main
git switch -c feature/xxx

9.6.6 上传代码到自己的开发分支

git status
git add <文件名>
git commit -m "feat: 增加某功能"
git push -u origin feature/xxx

如果已经推送过这个分支，后续可以直接执行：

git add <文件名>
git commit -m "fix: 修复某问题"
git push

如果是把当前目录全部改动一起提交：

git add .
git commit -m "docs: 更新说明文档"
git push

9.6.7 查看本次改了什么

git diff
git diff --staged
git log --oneline --graph --decorate -20

适用场景：

• 提交前自查改动
• 查看已暂存内容
• 查看最近提交历史

9.6.8 发起 PR 前，把主分支最新改动同步到功能分支

推荐做法是先把远程主分支合并到自己的功能分支：

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

如果没有冲突，继续推送：

git push

说明：

• 团队如果统一要求 rebase，则按团队规范执行
• 如果团队没有明确规定，优先用 merge，更稳妥，也更容易让新人理解

9.6.9 处理合并冲突

当 git merge origin/main 或 git pull 出现冲突时：

git status

手工编辑冲突文件后，执行：

git add <冲突文件>
git commit -m "merge: 解决与 main 的冲突"
git push

如果想放弃这次未完成的合并：

git merge --abort

9.6.10 PR 审查后继续补充提交

如果评审人提出修改意见，不需要新建分支，直接在原分支继续提交即可：

git switch feature/xxx
git add <文件名>
git commit -m "fix: 根据评审意见调整"
git push

推送后，GitCode 页面上的同一个 PR 会自动更新。

9.6.11 维护者本地合并分支

通常建议在 GitCode 页面完成 PR 合并，这样评审记录、流水线状态和审计信息更完整。

如果团队允许维护者在本地执行合并，可按下面做：

git fetch origin
git switch main
git pull origin main
git merge --no-ff feature/xxx
git push origin main

说明：

• --no-ff 可以保留一次完整的功能分支合并记录
• 如果仓库启用了保护分支，最终仍要以 GitCode 页面规则为准

9.6.12 合并完成后删除分支

本地删除已合并分支：

git branch -d feature/xxx

删除远程分支：

git push origin --delete feature/xxx

9.6.13 拉取远程最新代码

如果只是同步当前分支最新代码：

git pull

如果想先看远程更新，再决定是否合并：

git fetch origin
git log --oneline HEAD..origin/main

9.6.14 打标签和发布版本

版本发布常用命令：

git switch main
git pull origin main
git tag -a v1.0.0 -m "release v1.0.0"
git push origin v1.0.0

说明：

• Git 标签推送后，可在 GitCode 页面进一步创建 Release

9.6.15 安全回滚某次提交

如果某次提交已经推到远程，不建议直接 reset 改历史，推荐用 revert：

git switch main
git pull origin main
git revert <提交SHA>
git push origin main

适用场景：

• 已上线代码需要安全撤回
• 不希望破坏公共分支历史

9.6.16 临时保存当前未完成修改

git stash push -m "wip: 临时保存当前修改"
git stash list
git stash pop

适用场景：

• 需要临时切分支处理紧急问题
• 当前改动还不适合提交

9.6.17 常见命令使用建议

• git push -u origin <分支名>：第一次把本地分支推到远程时使用
• git push：已建立跟踪关系后使用
• git pull origin main：明确从远程主分支拉取代码
• git merge origin/main：把主分支最新代码合入当前功能分支
• git revert <提交SHA>：用于公共分支的安全撤销

9.6.18 GitCode 页面与命令行的职责分工

建议这样分工：

• 本地命令行：克隆、切分支、提交、推送、同步、解决冲突、打标签
• GitCode 页面：创建 PR、指定评审人、代码审查、查看流水线、点击合并、关闭 Issue、管理成员权限

这样做的好处是：

• 本地开发动作更高效
• 平台上的审计记录更完整
• 团队成员更容易形成统一流程

---

10. 推荐的源码管理规范

下面这部分不是平台死规则，而是团队最常见、最实用的治理方式。

10.1 分支治理建议

推荐保留以下主干结构：

• main：稳定主线
• develop：可选，作为集成分支
• release/*：版本发布分支
• hotfix/*：线上紧急修复分支

小团队建议：

• 用 main + feature/* 即可

中大型团队建议：

• 用 main + develop + release/* + hotfix/*

10.2 保护分支建议

GitCode 的保护分支能力主要用于保证代码安全、稳定和一致性。建议至少保护：

• main
• master（如历史项目仍在使用）
• release/*
• hotfix/*

建议启用的保护策略：

• 禁止直接推送到主分支
• 只能通过 PR 合并
• 要求评审通过后才能合并
• 要求流水线通过后才能合并
• 限制只有特定角色可以合并

10.3 PR 设置建议

GitCode 当前 PR 设置中，建议优先考虑以下规则：

• 设置最低评审人数
• 开启"评审问题全部解决才能合入"
• 开启"流水线运行通过"
• 开启"禁止合入自己创建的 Pull Request"
• 仅在紧急场景下保留"允许管理员强制合入"

推荐值：

• 通用业务仓：最低评审人数 = 1
• 核心基础库、嵌入式底层、算法仓：最低评审人数 = 2

10.4 标签、里程碑和模板

建议在项目早期就配置：

• Issue 模板
• PR 模板
• 标签体系
• 里程碑

推荐标签：

• bug
• feature
• docs
• urgent
• needs-review
• blocked
• question

GitCode 官方支持将模板放在以下位置：

.gitcode/ISSUE_TEMPLATE/
.gitcode/PULL_REQUEST_TEMPLATE/
docs/
.gitcode/

注意：

• 模板必须放在默认分支上才会生效
• GitCode 官方示例说明兼容 .github 目录，但团队内部建议优先统一使用 .gitcode 目录，减少歧义

10.5 推荐目录示例

.gitcode/
  ISSUE_TEMPLATE/
    bug.md
    feature.md
  PULL_REQUEST_TEMPLATE/
    default.md
  workflows/
    ci.yml
docs/
README.md

---

11. 团队协作怎么配合

下面给一套最常用、最稳妥的协作闭环。

11.1 标准协作闭环

1. 提需求或报问题
2. 创建 Issue
3. 打标签、定优先级、定负责人
4. 放入里程碑或看板
5. 负责人创建分支开发
6. 提交代码并推送分支
7. 创建 PR
8. 指定审查人 / 评审人 / 合并人
9. 运行流水线
10. 审查意见处理完成
11. PR 合并
12. 关闭关联 Issue
13. 更新看板状态
14. 打 Tag / 发布版本

11.2 Issue 的使用方式

Issue 不只是提 Bug，也适合记录：

• 新需求
• 技术债
• 优化任务
• 测试问题
• 文档任务
• 讨论事项

Issue 建议字段最少包括：

• 标题
• 背景
• 现象或目标
• 验收标准
• 负责人
• 优先级
• 关联版本或里程碑

11.3 看板的使用方式

GitCode 看板适合做任务状态可视化管理。

建议建立基础列：

• 待办
• 进行中
• 待评审
• 待测试
• 已完成

常见使用方式：

• 产品或负责人把 Issue 放进看板
• 开发者从"待办"领任务
• 开发中移动到"进行中"
• 提 PR 后移到"待评审"
• 合并后移到"已完成"

11.4 PR 的使用方式

GitCode PR 创建时可以指定：

• 合并人
• 审查人
• 评审人

建议：

• 发 PR 前先自查一遍
• 标题写清楚改动目的
• 描述里写清"改了什么、为什么改、影响范围、如何验证"
• 如改动较大，拆分成多个 PR，不要一次塞太多内容

11.5 流水线的使用方式

GitCode 流水线用于自动化构建、测试和部署。

工作流通常放在：

.gitcode/workflows

建议至少配置这些自动检查：

• 编译检查
• 单元测试
• 静态检查
• 打包检查

如果项目允许，进一步增加：

• 集成测试
• 制品发布
• 自动部署到测试环境

11.6 讨论和评论的使用方式

建议把讨论位置区分清楚：

• 需求澄清：Issue
• 代码细节：PR 评论
• 组织级长期交流：讨论区
• 状态同步：看板和里程碑

不要把所有事情都放在聊天工具里，因为难追溯。

---

12. 多方协同怎么落地

这里的"多方协同"通常指：

• 产品
• 开发
• 测试
• 运维
• 外部合作方
• 开源贡献者

12.1 一个典型的多方协同角色分工

参与方	建议角色	主要工作
组织负责人	Owner	权限治理、项目归属、重大决策
技术负责人	Maintainer	评审、合并、发布、规范维护
开发工程师	Developer	分支开发、提交代码、处理评审
测试工程师	Reporter / 自定义角色	提 Issue、回归验证、验收
产品经理	Reporter	提需求、确认验收标准、跟踪进度
运维或发布人员	Maintainer / 自定义角色	版本发布、流水线、部署配合
外部合作方	Guest / Reporter / Developer	按最小权限原则参与

12.2 企业内部多团队协同建议

如果一个组织下有多个研发方向，建议按模块拆项目：

• platform-backend
• platform-frontend
• platform-device
• platform-docs

再统一使用：

• 组织级成员管理
• 统一标签规范
• 统一 PR 规则
• 统一模板
• 统一默认分支命名

12.3 外部合作方协同建议

如果需要让外包、供应商或客户参与，建议：

• 优先把合作仓库设为独立权限模式
• 仅开放必要项目
• 先给 Guest 或 Reporter
• 真要提交代码时再升级为 Developer
• 主分支必须保护
• 合并权限尽量只留给内部 Maintainer

12.4 开源项目协同建议

如果项目公开，GitCode 官方说明中，登录用户可能拥有这些基础能力：

• 创建 Issue
• 创建 PR
• 发表评论
• 克隆或下载代码
• 查看 Wiki、讨论和公开看板

因此开源项目建议：

• 明确贡献指南
• 配置 Issue 模板
• 配置 PR 模板
• 配置标签
• 配置最低评审人数
• 打开保护分支

如果启用了轻量级 PR，要更注意审核流程，因为官方说明该功能不依赖代码推送权限。

如果不希望把外部贡献者直接加入组织或项目成员，也可以采用更稳妥的方式：

1. 外部贡献者 Fork 项目
2. 在自己的 Fork 仓库中创建分支开发
3. 推送到个人 Fork 仓库
4. 向上游仓库发起 PR
5. 由内部 Maintainer 完成评审和合并

---

13. 推荐的一套详细操作流程

下面给一套可以直接执行的标准流程。

阶段一：建立协作环境

1. 注册 GitCode 账号
2. 配置本地 Git 身份
3. 配置 SSH Key
4. 创建组织
5. 配置组织基础信息
6. 配置组织默认设置

阶段二：建立项目

1. 在组织下创建代码仓
2. 选择私密或公开
3. 初始化 README.md、.gitignore
4. 确定默认分支名称
5. 视情况选择继承模式或独立模式

阶段三：建立治理规则

1. 配置项目成员和组织成员
2. 分配 Owner / Maintainer / Developer / Reporter / Guest
3. 建立标签体系
4. 建立 Issue 模板和 PR 模板
5. 建立里程碑
6. 建立看板
7. 配置保护分支
8. 配置 PR 设置
9. 配置流水线

阶段四：开始协作开发

1. 产品或负责人创建 Issue
2. 分配负责人
3. 开发者从主分支拉新分支
4. 本地开发并提交
5. 推送远程分支
6. 创建 PR
7. 指定审查人
8. 流水线自动检查
9. 根据评审意见修改
10. 评审通过后由维护者合并
11. 关闭 Issue
12. 更新看板

阶段五：发布和维护

1. 在稳定版本打 Tag
2. 按需创建 Release
3. 对历史版本做归档或维护
4. 通过 Issue 和里程碑跟踪后续版本

---

14. 常见管理场景处理建议

14.1 新员工加入

建议流程：

1. 加入组织
2. 分配角色
3. 加入对应项目
4. 完成 SSH Key 配置
5. 克隆仓库
6. 阅读 README、贡献规范、分支规范、PR 规范
7. 先从小 Issue 开始

14.2 成员转岗或权限调整

建议流程：

1. 修改组织或项目角色
2. 审查其在关键仓库中的访问权限
3. 审查其是否仍需要合并权限或发布权限

14.3 成员离职或合作结束

建议流程：

1. 移出组织
2. 移出项目
3. 撤销邀请链接
4. 清理关联设备密钥和自动化凭据
5. 交接未完成 Issue、PR、看板任务

14.4 紧急修复

建议流程：

1. 从稳定分支创建 hotfix/*
2. 修复后提交 PR
3. 至少完成必要评审和测试
4. 合并到主分支
5. 如有 develop 分支，再同步回开发线

14.5 多项目并行开发

建议流程：

1. 每个项目明确 Maintainer
2. 组织级统一标签和模板
3. 组织级统一评审和流水线策略
4. 在组织看板或版本节奏上做统一管理

---

15. 注意事项清单

以下是最容易踩坑的地方。

15.1 创建项目时

• 项目路径必须唯一
• 公开项目前必须检查敏感信息
• 不要把团队长期项目建在个人账号下
• 迁移项目前先确认哪些内容不会被一起迁移

15.2 管理权限时

• 不要给太多人 Owner
• 不要默认所有人都是 Maintainer
• 优先使用最小权限原则
• 特殊项目优先使用独立权限模式

15.3 邀请成员时

• 邀请链接有有效期且可能可重复使用
• 邀请链接不要发到公开群
• 短期合作建议设置短时效链接

15.4 管理源代码时

• 不要直接往主分支推代码
• 不要跳过 PR 评审
• 不要把大改动堆成一个超大 PR
• 不要把本地配置文件、密钥、日志、构建产物提交进仓库

15.5 模板和自动化时

• Issue / PR 模板要放在默认分支
• 流水线文件建议统一放在 .gitcode/workflows
• 保护分支规则和 PR 规则要协同配置，不要只配其中一个

15.6 人员变动时

• 成员离开当天就要回收权限
• 不仅要移除成员，还要检查密钥、凭据、自动化集成
• 项目负责人变更时，要同步交接看板、里程碑和未合并 PR

---

16. 推荐的一页式团队规范

如果你们想快速落地，可以直接采用下面这一套：

16.1 权限规范

• 组织 Owner：2 人以内
• 项目 Maintainer：每仓 1 到 3 人
• 开发人员：默认 Developer
• 测试/产品：默认 Reporter
• 外部合作方：默认 Guest 或 Reporter

16.2 分支规范

• 主分支：main
• 功能分支：feature/*
• 缺陷分支：bugfix/*
• 紧急修复：hotfix/*
• 发布分支：release/*

16.3 合并规范

• 禁止直接推主分支
• 所有改动必须走 PR
• 至少 1 名评审通过
• 核心仓至少 2 名评审通过
• 流水线必须通过
• 原则上禁止自合并

16.4 Issue 规范

• 一项任务一个 Issue
• Issue 必须有负责人
• Issue 必须有标签
• 大版本任务必须挂里程碑

16.5 PR 规范

• 标题写明变更目的
• 描述写明影响范围
• 大改动拆小 PR
• 合并前处理完评审意见

---

17. 官方参考链接

以下链接为本文整理时使用的 GitCode 官方帮助文档：

• 组织管理：https://docs.gitcode.com/docs/help/home/user_center/data_management/organization_management/
• 项目创建、导入与迁移：https://docs.gitcode.com/docs/help/home/org_project/project_manage/getting_started/project_creation_and_import/
• 组织成员：https://docs.gitcode.com/docs/help/home/org_project/org/org-member/
• 组织项目与个人项目权限说明：https://docs.gitcode.com/docs/help/home/org_project/project_manage/permission_management/organization_and_personal_permissions/
• 角色与权限：https://docs.gitcode.com/docs/help/home/org_project/org/org-setup/org-character/
• 自定义角色：https://docs.gitcode.com/docs/help/home/org_project/org/org-setup/member-manage/
• 项目成员管理：https://docs.gitcode.com/docs/help/home/org_project/project_manage/permission_management/project_member_management/
• SSH 公钥管理：https://docs.gitcode.com/docs/help/home/user_center/security_management/ssh/
• 创建 Pull Request：https://docs.gitcode.com/docs/help/home/org_project/pullrequests/pr-create/
• PR 设置：https://docs.gitcode.com/docs/help/home/org_project/project_manage/project_settings/pr_settings/
• 看板快速上手：https://docs.gitcode.com/docs/help/home/org_project/kanban/quick_start/
• 流水线：https://docs.gitcode.com/docs/help/home/org_project/pipeline/pipeline-intro1/
• Issue 模板：https://docs.gitcode.com/docs/help/home/org_project/issue/issue_template/
• Pull Request 模板：https://docs.gitcode.com/docs/help/home/org_project/pullrequests/pr-template/
• 快速入门：https://docs.gitcode.com/docs/start/quick/

---

18. 结论

注意事项：

1. 团队项目优先建在组织下，不要长期挂在个人账号下
2. 用角色和权限管理人，而不是靠口头约定
3. 用分支、PR、评审、流水线管理代码，而不是直接推主分支
4. 用 Issue、看板、里程碑管理协同，而不是只靠聊天工具
5. 人员变动时，权限、密钥、凭据一定要同步回收