Basic Gitea Information
Basic Structure
基本的なGitea環境の構造は、組織ごとにリポジトリをグループ化することです。各組織には複数のリポジトリと複数のチームが含まれる場合があります。ただし、githubと同様に、ユーザーは組織外にリポジトリを持つことができます。
さらに、ユーザーは異なる組織のメンバーになることができます。組織内では、ユーザーは各リポジトリに対して異なる権限を持つことができます。
ユーザーはまた、異なるリポジトリに対して異なる権限を持つ異なるチームの一部である場合もあります。
最後に、リポジトリには特別な保護メカニズムがある場合があります。
Permissions
Organizations
組織が作成されると、Ownersというチームが作成され、ユーザーがその中に入れられます。このチームは組織に対する管理アクセスを提供し、その権限とチームの名前は変更できません。
組織管理者（オーナー）は、組織の可視性を選択できます：
Public
Limited (ログインユーザーのみ)
Private (メンバーのみ)
組織管理者はまた、リポジトリ管理者がチームのアクセスを追加または削除できるかどうかを指定できます。リポジトリの最大数も指定できます。
新しいチームを作成する際には、いくつかの重要な設定が選択されます：
チームのメンバーがアクセスできる組織のリポジトリを指定します：特定のリポジトリ（チームが追加されたリポジトリ）またはすべて。
メンバーが新しいリポジトリを作成できるかどうかも指定します（作成者は管理アクセスを取得します）。
リポジトリのメンバーが持つ権限：
管理者アクセス
特定のアクセス：
Teams & Users
リポジトリでは、組織管理者および（組織が許可する場合）リポジトリ管理者が、コラボレーター（他のユーザー）およびチームに与えられる役割を管理できます。3つの可能な役割があります：
管理者
書き込み
読み取り
Gitea Authentication
Web Access
ユーザー名 + パスワードと、可能であれば（推奨）2FAを使用します。
SSH Keys
アカウントを1つまたは複数の公開鍵で設定し、関連する秘密鍵があなたの代わりにアクションを実行できるようにします。 http://localhost:3000/user/settings/keys
GPG Keys
これらの鍵を使用してユーザーを偽装することはできませんが、使用しない場合、署名なしでコミットを送信することで発見される可能性があります。
Personal Access Tokens
個人用アクセス トークンを生成して、アプリケーションにアカウントへのアクセスを許可できます。個人用アクセス トークンはアカウント全体へのアクセスを提供します: http://localhost:3000/user/settings/applications
Oauth Applications
個人用アクセス トークンと同様に、Oauth アプリケーションはアカウントおよびアカウントがアクセスできる場所に対して完全なアクセス権を持ちます。なぜなら、docsに記載されているように、スコープはまだサポートされていないからです：
Deploy keys
デプロイキーはリポジトリへの読み取り専用または書き込みアクセスを持つ場合があり、特定のリポジトリを侵害するために興味深いものとなる可能性があります。
Branch Protections
ブランチ保護は、リポジトリの完全な制御をユーザーに与えないように設計されています。目的は、いくつかの保護方法を設けて、特定のブランチにコードを書き込む前に保護することです。
リポジトリのブランチ保護は https://localhost:3000/<orgname>/<reponame>/settings/branches にあります。
組織レベルでブランチ保護を設定することはできません。したがって、すべてのリポジトリで宣言する必要があります。
ブランチに対して適用できるさまざまな保護（例えば、masterに対して）：
プッシュを無効にする：誰もこのブランチにプッシュできません
プッシュを有効にする：アクセス権を持つ人は誰でもプッシュできますが、強制プッシュはできません。
ホワイトリスト制限付きプッシュ：選択されたユーザー/チームのみがこのブランチにプッシュできます（ただし強制プッシュはできません）
マージホワイトリストを有効にする：ホワイトリストに登録されたユーザー/チームのみがPRをマージできます。
ステータスチェックを有効にする：マージする前にステータスチェックが合格する必要があります。
承認を要求する：PRをマージする前に必要な承認の数を指定します。
ホワイトリストに登録されたユーザー/チームに承認を制限する：PRを承認できるユーザー/チームを指定します。
拒否されたレビューでマージをブロックする：変更が要求された場合、他のチェックが合格してもマージできません。
公式レビューリクエストでマージをブロックする：公式レビューリクエストがある場合、マージできません。
古い承認を無効にする：新しいコミットがあると、古い承認は無効になります。
署名付きコミットを要求する：コミットは署名されている必要があります。
プルリクエストが古い場合はマージをブロックする
保護/非保護ファイルパターン：変更に対して保護/非保護するファイルのパターンを指定します。
ご覧のとおり、ユーザーの資格情報を取得したとしても、リポジトリが保護されているため、例えばCI/CDパイプラインを侵害するためにmasterにコードをプッシュすることができない場合があります。
Last updated
