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