Grundlegende Gitea-Informationen

Reading time: 5 minutes

Grundstruktur

Die grundlegende Gitea-Umgebungsstruktur besteht darin, Repos nach Organisation(en) zu gruppieren, von denen jede mehrere Repositories und mehrere Teams enthalten kann. Beachten Sie jedoch, dass Benutzer wie bei GitHub Repos außerhalb der Organisation haben können.

Darüber hinaus kann ein Benutzer ein Mitglied von verschiedenen Organisationen sein. Innerhalb der Organisation kann der Benutzer verschiedene Berechtigungen für jedes Repository haben.

Ein Benutzer kann auch Teil verschiedener Teams mit unterschiedlichen Berechtigungen für verschiedene Repos sein.

Und schließlich können Repositories spezielle Schutzmechanismen haben.

Berechtigungen

Organisationen

Wenn eine Organisation erstellt wird, wird ein Team namens Owners erstellt und der Benutzer wird darin platziert. Dieses Team gewährt Admin-Zugriff auf die Organisation, diese Berechtigungen und der Name des Teams können nicht geändert werden.

Org-Admins (Eigentümer) können die Sichtbarkeit der Organisation auswählen:

• Öffentlich
• Eingeschränkt (nur angemeldete Benutzer)
• Privat (nur Mitglieder)

Org-Admins können auch angeben, ob die Repo-Admins Zugriff für Teams hinzufügen oder entfernen können. Sie können auch die maximale Anzahl von Repos angeben.

Beim Erstellen eines neuen Teams werden mehrere wichtige Einstellungen ausgewählt:

• Es wird angegeben, auf welche Repos der Org die Mitglieder des Teams zugreifen können: spezifische Repos (Repos, in die das Team hinzugefügt wird) oder alle.
• Es wird auch angegeben, ob Mitglieder neue Repos erstellen können (der Ersteller erhält Admin-Zugriff darauf).
• Die Berechtigungen, die die Mitglieder des Repos haben:
• Administrator-Zugriff
• Spezifischer Zugriff:

Teams & Benutzer

In einem Repo können der Org-Admin und die Repo-Admins (sofern von der Org erlaubt) die Rollen verwalten, die den Mitarbeitern (anderen Benutzern) und Teams zugewiesen sind. Es gibt 3 mögliche Rollen:

• Administrator
• Schreiben
• Lesen

Gitea-Authentifizierung

Webzugang

Verwendung von Benutzername + Passwort und möglicherweise (und empfohlen) einer 2FA.

SSH-Schlüssel

Sie können Ihr Konto mit einem oder mehreren öffentlichen Schlüsseln konfigurieren, die es dem zugehörigen privaten Schlüssel ermöglichen, in Ihrem Namen Aktionen auszuführen. http://localhost:3000/user/settings/keys

GPG-Schlüssel

Sie können den Benutzer mit diesen Schlüsseln nicht impersonifizieren, aber wenn Sie ihn nicht verwenden, könnte es möglich sein, dass Sie entdeckt werden, weil Sie Commits ohne Signatur senden.

Persönliche Zugriffstoken

Sie können persönliche Zugriffstoken generieren, um einer Anwendung Zugriff auf Ihr Konto zu gewähren. Ein persönliches Zugriffstoken gewährt vollen Zugriff auf Ihr Konto: http://localhost:3000/user/settings/applications

Oauth-Anwendungen

Genau wie persönliche Zugriffstoken haben Oauth-Anwendungen vollständigen Zugriff auf Ihr Konto und die Orte, auf die Ihr Konto Zugriff hat, da, wie in den Docs angegeben, Scopes noch nicht unterstützt werden:

Deploy-Schlüssel

Deploy-Schlüssel können Lese- oder Schreibzugriff auf das Repo haben, sodass sie interessant sein könnten, um spezifische Repos zu kompromittieren.

Branch-Schutz

Branch-Schutzmaßnahmen sind darauf ausgelegt, Benutzern nicht die vollständige Kontrolle über ein Repository zu geben. Das Ziel ist es, mehrere Schutzmethoden zu implementieren, bevor man in der Lage ist, Code in einen bestimmten Branch zu schreiben.

Die Branch-Schutzmaßnahmen eines Repositories finden Sie unter https://localhost:3000/<orgname>/<reponame>/settings/branches

Verschiedene Schutzmaßnahmen können auf einen Branch (wie auf master) angewendet werden:

• Push deaktivieren: Niemand kann in diesen Branch pushen.
• Push aktivieren: Jeder mit Zugriff kann pushen, aber nicht force pushen.
• Whitelist eingeschränkter Push: Nur ausgewählte Benutzer/Teams können in diesen Branch pushen (aber kein force push).
• Whitelist für Merge aktivieren: Nur aufgelistete Benutzer/Teams können PRs mergen.
• Statusprüfungen aktivieren: Erfordert, dass Statusprüfungen bestanden werden, bevor gemerged wird.
• Genehmigungen erforderlich: Gibt die Anzahl der erforderlichen Genehmigungen an, bevor ein PR gemerged werden kann.
• Genehmigungen auf Whitelist beschränken: Gibt Benutzer/Teams an, die PRs genehmigen können.
• Merge bei abgelehnten Überprüfungen blockieren: Wenn Änderungen angefordert werden, kann es nicht gemerged werden (auch wenn die anderen Prüfungen bestehen).
• Merge bei offiziellen Überprüfungsanfragen blockieren: Wenn es offizielle Überprüfungsanfragen gibt, kann es nicht gemerged werden.
• Veraltete Genehmigungen zurückweisen: Bei neuen Commits werden alte Genehmigungen zurückgewiesen.
• Signierte Commits erforderlich: Commits müssen signiert sein.
• Merge blockieren, wenn der Pull-Request veraltet ist.
• Geschützte/ungeschützte Dateimuster: Gibt Muster von Dateien an, die gegen Änderungen geschützt/ungeschützt werden sollen.