Basic Gitea Information
基本结构
基本的 Gitea 环境结构是通过 组织 来分组仓库，每个组织可以包含 多个仓库 和 多个团队。但是，请注意，正如在 GitHub 中，用户可以在组织外拥有仓库。
此外，用户 可以是 不同组织的成员。在组织内，用户可能对每个仓库拥有 不同的权限。
用户也可以是 不同团队的一部分，对不同仓库拥有不同的权限。
最后，仓库可能具有特殊的保护机制。
权限
组织
当 组织被创建 时，会创建一个名为 Owners 的团队，并将用户放入其中。该团队将提供对 组织 的 管理员访问，这些 权限 和团队的 名称 无法修改。
组织管理员（所有者）可以选择组织的 可见性：
公开
限制（仅限登录用户）
私有（仅限成员）
组织管理员 还可以指示 仓库管理员 是否可以 添加或移除 团队的访问权限。他们还可以指示最大仓库数量。
创建新团队时，会选择几个重要设置：
指定 团队成员可以访问的组织仓库：特定仓库（团队被添加的仓库）或所有仓库。
还指示 成员是否可以创建新仓库（创建者将获得管理员访问权限）
成员 在仓库中将 拥有的权限：
管理员 访问
特定 访问：
团队与用户
在仓库中，组织管理员 和 仓库管理员（如果组织允许）可以 管理 分配给合作者（其他用户）和团队的角色。可能的 角色 有 3 种：
管理员
写入
读取
Gitea 认证
网络访问
使用 用户名 + 密码，并可能（推荐）使用 2FA。
SSH 密钥
您可以使用一个或多个公钥配置您的帐户，允许相关的 私钥代表您执行操作。 http://localhost:3000/user/settings/keys
GPG 密钥
您 无法使用这些密钥冒充用户，但如果您不使用它，可能会因为 发送未签名的提交而被发现。
个人访问令牌
您可以生成个人访问令牌，以 授予应用程序访问您的帐户。个人访问令牌对您的帐户具有完全访问权限：http://localhost:3000/user/settings/applications
Oauth 应用程序
与个人访问令牌一样，Oauth 应用程序 将对您的帐户及其访问的地方具有 完全访问权限，因为如 文档 所示，范围尚不支持：
部署密钥
部署密钥可能对仓库具有只读或写入访问权限，因此它们可能对特定仓库的妥协很有趣。
分支保护
分支保护旨在 不将仓库的完全控制权授予用户。目标是在能够在某些分支中写入代码之前 设置几种保护方法。
仓库的分支保护 可以在 https://localhost:3000/<orgname>/<reponame>/settings/branches 中找到。
无法在组织级别设置分支保护。因此，所有保护必须在每个仓库中声明。
可以对分支（例如主分支）应用不同的保护：
禁用推送：无人可以推送到此分支
启用推送：任何有访问权限的人都可以推送，但不能强制推送。
白名单限制推送：只有选定的用户/团队可以推送到此分支（但不能强制推送）
启用合并白名单：只有白名单中的用户/团队可以合并 PR。
启用状态检查：要求状态检查在合并之前通过。
要求批准：指示在 PR 可以合并之前所需的批准数量。
限制批准给白名单：指示可以批准 PR 的用户/团队。
在拒绝审查时阻止合并：如果请求更改，则无法合并（即使其他检查通过）
在官方审查请求时阻止合并：如果有官方审查请求，则无法合并
撤销过期的批准：当有新提交时，旧的批准将被撤销。
要求签名提交：提交必须签名。
如果拉取请求过时则阻止合并
受保护/不受保护的文件模式：指示要保护/不保护的文件模式
正如您所看到的，即使您设法获得了用户的一些凭据，仓库可能受到保护，避免您将代码推送到主分支，例如，以妥协 CI/CD 管道。
Last updated
