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