Basic Gitea Information
基本構造
基本的なGitea環境の構造は、組織によってリポジトリをグループ化することです。各組織は複数のリポジトリと複数のチームを含むことができます。ただし、GitHubと同様に、ユーザーは組織外にリポジトリを持つことができます。
さらに、ユーザーは異なる組織のメンバーになることができます。組織内では、ユーザーは各リポジトリに対して異なる権限を持つことがあります。
ユーザーはまた、異なるリポジトリに対して異なる権限を持つ異なるチームの一員であることもできます。
最後に、リポジトリには特別な保護メカニズムがある場合があります。
権限
組織
組織が作成されると、Ownersというチームが作成され、ユーザーはその中に配置されます。このチームは組織に対する管理者アクセスを提供し、その権限とチーム名は変更できません。
Org admins（オーナー）は、組織の可視性を選択できます：
公開
限定（ログインユーザーのみ）
非公開（メンバーのみ）
Org adminsは、リポジトリ管理者がチームのアクセスを追加または削除できるかどうかも示すことができます。また、リポジトリの最大数を示すこともできます。
新しいチームを作成する際には、いくつかの重要な設定が選択されます：
チームのメンバーがアクセスできる組織のリポジトリが示されます：特定のリポジトリ（チームが追加されたリポジトリ）またはすべて。
メンバーが新しいリポジトリを作成できるかどうかも示されます（作成者はそのリポジトリに管理者アクセスを得ます）。
リポジトリのメンバーが持つ権限：
管理者アクセス
特定のアクセス：
チームとユーザー
リポジトリ内で、org adminとリポジトリ管理者（組織によって許可されている場合）は、コラボレーター（他のユーザー）やチームに与えられた役割を管理できます。可能な役割は3つです：
管理者
書き込み
読み取り
Gitea認証
ウェブアクセス
ユーザー名 + パスワードを使用し、可能であれば（推奨）2FAを使用します。
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を承認できるユーザー/チームを示します。
拒否されたレビューでのマージをブロックする：変更が要求された場合、マージできません（他のチェックが通過しても）
公式レビューリクエストでのマージをブロックする：公式レビューリクエストがある場合、マージできません
古い承認を無効にする：新しいコミットがあると、古い承認は無効になります。
署名されたコミットを要求する：コミットは署名されなければなりません。
プルリクエストが古くなった場合はマージをブロックする
保護された/保護されていないファイルパターン：変更から保護/保護解除するファイルのパターンを示します
ご覧のとおり、ユーザーの資格情報を取得できたとしても、リポジトリが保護されているため、例えばmasterにコードをプッシュすることを避けることができます。
Last updated
