基本的なGitea情報

Reading time: 9 minutes

基本構造

基本的な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アプリケーションはあなたのアカウントとあなたのアカウントがアクセスできる場所に対して完全なアクセスを持ちます。なぜなら、docsに示されているように、スコープはまだサポートされていないからです：

デプロイキー

デプロイキーはリポジトリに対して読み取り専用または書き込みアクセスを持つことができるため、特定のリポジトリを侵害するのに興味深いかもしれません。

ブランチ保護

ブランチ保護は、ユーザーにリポジトリの完全な制御を与えないように設計されています。目標は、いくつかの保護方法を設けて、特定のブランチ内にコードを書くことができるようにすることです。

リポジトリのブランチ保護は、_https://localhost:3000/<orgname>/<reponame>/settings/branches_で見つけることができます。

ブランチに適用できるさまざまな保護があります（例えば、masterに）：

• プッシュを無効にする：誰もこのブランチにプッシュできません
• プッシュを有効にする：アクセス権のある誰でもプッシュできますが、強制プッシュはできません。
• ホワイトリスト制限プッシュを有効にする：選択されたユーザー/チームのみがこのブランチにプッシュできます（ただし、強制プッシュはできません）。
• マージホワイトリストを有効にする：ホワイトリストに登録されたユーザー/チームのみがPRをマージできます。
• ステータスチェックを有効にする：マージする前にステータスチェックが通過することを要求します。
• 承認を要求する：PRをマージする前に必要な承認の数を示します。
• ホワイトリストに制限された承認：PRを承認できるユーザー/チームを示します。
• 拒否されたレビューでのマージをブロックする：変更が要求された場合、マージできません（他のチェックが通過しても）。
• 公式レビューリクエストでのマージをブロックする：公式レビューリクエストがある場合、マージできません。
• 古い承認を無効にする：新しいコミットがあると、古い承認は無効になります。
• 署名されたコミットを要求する：コミットは署名されなければなりません。
• プルリクエストが古くなった場合はマージをブロックする
• 保護された/保護されていないファイルパターン：変更から保護/保護解除するファイルのパターンを示します。