Erste Schritte

Du hast ein managed Forgejo bei server.camp bestellt – herzlichen Glückwunsch! Forgejo ist eine schlanke, schnelle Git-Plattform für deine gesamte Softwareentwicklung – von der Code-Verwaltung über Issues und Code-Reviews bis hin zu einer eigenen Package-Registry. Diese Anleitung richtet sich an Entwicklungsteams in KMU, Freelancer und Vereine, die professionelle Versionskontrolle und Zusammenarbeit auf eigener Infrastruktur nutzen wollen.

GitHub ist ein guter Einstieg – aber für Unternehmen und Teams gibt es überzeugende Gründe, eine eigene Forgejo-Instanz bei server.camp zu betreiben:

Für wen lohnt sich ein eigenes Forgejo?

Ein eigenes Forgejo lohnt sich, sobald eines dieser Kriterien zutrifft: du arbeitest mit Kundendaten oder proprietärem Code, du willst keine Pro-Nutzer-Kosten zahlen, du musst DSGVO-Konformität nachweisen, oder du willst eine schlanke Plattform mit vollem Admin-Zugriff. Forgejo ist besonders ressourcenschonend – ideal, wenn du eine schnelle, übersichtliche Git-Plattform ohne Overhead suchst.

Nach der Bestellung erhältst du von uns eine E-Mail mit dem Link zu deiner Forgejo-Instanz und den Zugangsdaten. Der initiale Account ist der Administrator mit dem Benutzernamen root.

1. Öffne den Link aus der E-Mail und melde dich mit dem Benutzernamen root und dem zugesendeten Passwort an.
2. Beim ersten Login wirst du aufgefordert, das Passwort zu ändern – wähle ein sicheres, einzigartiges Passwort.
3. Den Admin-Bereich erreichst du jederzeit über das Profilsymbol oben rechts → “Administration”.

Admin-Zugangsdaten sicher aufbewahren

Der root-Account hat vollen Zugriff auf deine Instanz. Bewahre die Zugangsdaten sicher auf – am besten in einem Passwort-Manager wie Vaultwarden. Aktiviere zusätzlich die Zwei-Faktor-Authentifizierung.

Eigenen Arbeits-Account anlegen

Nutze den root-Account nur für administrative Aufgaben. Lege dir für die tägliche Arbeit (Commits, Pull Requests, Issues) einen eigenen, persönlichen Account an. So bleiben administrative und inhaltliche Tätigkeiten sauber getrennt.

Aus Sicherheitsgründen ist die offene Registrierung standardmäßig deaktiviert. Neue Nutzer legst du als Administrator selbst an:

1. Gehe zu Administration → Identität & Zugriff → Nutzerkonten.
2. Klicke auf “Nutzerkonto erstellen” und vergib Benutzername, E-Mail-Adresse und ein initiales Passwort.
3. Der neue Nutzer kann sich anschließend anmelden und sein Passwort ändern.

Offene Registrierung auf Wunsch aktivierbar

Falls du die Selbstregistrierung erlauben möchtest – über die Instanz-Einstellungen im Dashboard kannst du die Registrierung entweder komplett öffnen oder auf bestimmte E-Mail-Domains (z. B. nur @deine-firma.de) limitieren.

Für die tägliche Arbeit mit Git empfiehlt sich die Authentifizierung per SSH-Key statt Passwort:

1. SSH-Key generieren (falls noch keiner vorhanden): ssh-keygen -t ed25519
2. Den öffentlichen Schlüssel (~/.ssh/id_ed25519.pub) kopieren
3. In Forgejo: Benutzereinstellungen → SSH-/GPG-Schlüssel → Schlüssel hinzufügen
4. Ab sofort: git clone git@dein-forgejo.srv.camp:gruppe/repo.git

Forgejo ist einfach aufgebaut:

• Nutzer – ein persönliches Konto mit eigenen Repositories
• Organisation – ein gemeinsamer Bereich für ein Team, einen Kunden oder ein Projekt, mit eigener Rechteverwaltung
• Repository – das eigentliche Git-Repository (privat oder öffentlich), in dem dein Code, deine Issues, Pull Requests und das Wiki leben

Organisationen sind ideal, um Repositories für ein Team zu bündeln und Zugriffsrechte zentral über Teams zu vergeben.

Über das Plus-Symbol oben rechts legst du neue Inhalte an:

• Neues Repository – Name vergeben, Sichtbarkeit (privat oder öffentlich) wählen, optional README und .gitignore initialisieren. Der Default-Branch ist main.
• Neue Organisation – Name vergeben und anschließend Teams und Mitglieder hinzufügen.

Rechte über Organisationen und Teams steuern

Lege für jeden Kunden oder internen Bereich eine eigene Organisation an. Innerhalb der Organisation erstellst du Teams (z. B. “Entwickler”, “Reviewer”) und vergibst deren Zugriffsrechte zentral. So musst du nicht jedes Repository einzeln konfigurieren – und ein externer Entwickler, der nur an einem Kunden arbeitet, bekommt nur Zugriff auf dessen Organisation.

🏢 Intern
   📦 infrastructure (Ansible, Docker-Configs)
   📦 libraries (wiederverwendbare Module)
   📦 tools (interne Skripte)
🏢 Kunde-A
   📦 frontend
   📦 backend
   📦 dokumentation
🏢 Kunde-B
   📦 ...

Installiere zunächst Git auf deinem Rechner.

# Per SSH (empfohlen)
git clone git@dein-forgejo.srv.camp:gruppe/repo.git

# Per HTTPS
git clone https://dein-forgejo.srv.camp/gruppe/repo.git

# Geänderte Dateien für den nächsten Commit vormerken
git add .

# Änderungen als Commit speichern
git commit -m "Kurze Beschreibung, was geändert wurde"

# Änderungen zu Forgejo hochladen
git push

Branches erlauben es, an Features oder Bugfixes zu arbeiten, ohne den Hauptentwicklungszweig zu beeinflussen:

# Neuen Branch erstellen und wechseln
git checkout -b feature/neue-funktion

# Änderungen im Branch committen
git add .
git commit -m "Login-Seite implementiert"

# Branch zu Forgejo hochladen
git push -u origin feature/neue-funktion

Tipp: kurzlebige Branches sind einfacher in der Handhabung

Je kürzer ein Branch lebt, desto einfacher ist die Handhabung. Arbeite an einem Feature, erstelle einen Pull Request, reviewe und merge – und lösche den Branch anschließend. So vermeidest du lange lebende Branches, die mit dem Hauptbranch auseinanderdriften und schwer zu mergen sind.

Folgenden Workflow empfehlen wir für Teams:

1. Jede Änderung passiert in einem eigenen Branch
2. Wenn die Entwicklung fertig ist, wird ein Pull Request (PR) erstellt
3. Ein Teamkollege reviewt den Code und gibt Feedback oder genehmigt
4. Nach Genehmigung wird der Branch in den Hauptbranch gemergt

1. In Forgejo zum Repository navigieren → Tab “Pull Requests” → “Neuer Pull Request”
2. Source-Branch (dein Feature-Branch) und Ziel-Branch (z. B. main) auswählen
3. Titel und Beschreibung eintragen – was wurde geändert und warum?
4. Reviewer zuweisen, optional Labels und Milestone verknüpfen
5. Auf “Pull Request erstellen” klicken

Als Reviewer:

1. Pull Request öffnen → Tab “Dateien geändert” zeigt alle Code-Änderungen
2. Zeile anklicken → Kommentar hinterlassen (Fragen, Verbesserungsvorschläge, Lob)
3. Oben rechts auf den “Begutachten”-Button klicken und die Review mit “Genehmigen” abschließen (alternativ “Änderungen anfordern” oder “Kommentar”)
4. Der Autor kann den PR anschließend zusammenführen

main-Branch schützen

Aktiviere unter Repository-Einstellungen → Branches → Branch-Schutzregeln den Schutz für main. So kann niemand direkt in den Hauptbranch pushen – alles muss über einen Pull Request mit Review gehen. Das verhindert versehentliche Fehler im Produktivcode und etabliert ein Vier-Augen-Prinzip.

Forgejo bringt alles mit, um Aufgaben direkt am Code zu organisieren:

• Issues – Aufgaben, Bugs oder Feature-Anfragen mit Titel, Beschreibung (Markdown), Zuweisung und Fälligkeitsdatum.
• Labels – Kategorisierung (z. B. bug, feature, dringend, backlog).
• Milestones – Meilensteine mit Fälligkeitsdatum, um Issues für ein Release oder einen Sprint zu bündeln und den Fortschritt zu verfolgen.
• Projekte (Kanban) – ein Board mit Spalten (z. B. To Do → In Arbeit → Review → Fertig), auf dem du Issues per Drag-and-Drop verschiebst.

Issues mit Pull Requests verknüpfen

Schreibe Closes #42 in die Beschreibung deines Pull Requests, damit das zugehörige Issue automatisch geschlossen wird, sobald der PR gemergt ist. So bleiben Code und Aufgaben sauber miteinander verbunden.

Jedes Repository hat ein integriertes Wiki für technische Dokumentation:

• Markdown-basiert
• Eigenständiges Git-Repository (kann geklont und lokal bearbeitet werden)
• Seitenleiste mit Navigation

Typische Wiki-Inhalte: Architektur-Übersicht, Einrichtungsanleitung für Entwickler, Deployment-Prozess, Entscheidungsprotokolle.

Wiki vs. README

Nutze die README.md im Repository für den schnellen Überblick (Was ist das Projekt? Wie starte ich es?). Nutze das Wiki für ausführliche Dokumentation, die über das Repository hinausgeht.

Unter dem Tab “Releases” kannst du auf Basis von Git-Tags Versionen veröffentlichen, Release-Notes hinterlegen und Binärdateien (z. B. fertige Builds) als Anhänge bereitstellen. Ideal, um deinem Team oder deinen Nutzern klar definierte Versionsstände zur Verfügung zu stellen.

Forgejo bringt mit Forgejo Actions eine integrierte CI/CD-Funktion mit. Sie ist standardmäßig aktiviert und in der Syntax weitgehend kompatibel zu GitHub Actions. Workflows definierst du als YAML-Dateien im Verzeichnis .forgejo/workflows/ deines Repositories (alternativ liest Forgejo auch .github/workflows/, was die Migration bestehender GitHub-Actions-Workflows erleichtert). Bei einem passenden Ereignis (z. B. ein Push) wird der Workflow ausgelöst.

on: [push]

jobs:
  test:
    runs-on: docker
    steps:
      - uses: actions/checkout@v6
      - run: npm ci
      - run: npm test

Runner sind nicht inklusive – aber als Add-on buchbar

Forgejo Actions benötigt einen Forgejo Runner – ein System, das die Workflow-Schritte tatsächlich ausführt. Im Hosting ist standardmäßig kein Runner enthalten. Bei server.camp kannst du einen Runner aber günstig als Add-on zu deinem Forgejo dazubestellen – dann übernehmen wir Betrieb und Wartung für dich. Alternativ betreibst du einen eigenen Runner.

Option 1: Runner-Add-on bei server.camp buchen

Am einfachsten buchst du einen Runner direkt als günstiges Add-on zu deinem Forgejo. Der Runner läuft isoliert für deine Instanz, und wir kümmern uns um Betrieb und Updates. Wende dich dazu an unseren Support oder schau auf der Produktseite von Forgejo vorbei.

Option 2: Eigenen Forgejo Runner betreiben

Du kannst einen Forgejo Runner auch selbst auf einem eigenen Server, einem Entwickler-Rechner oder in einer VM betreiben. Eine Schritt-für-Schritt-Anleitung findest du in der offiziellen Forgejo-Actions-Dokumentation.

Actions ist optional

Du kannst Forgejo zunächst vollständig ohne Actions nutzen – Repositories, Issues, Pull Requests und Wiki funktionieren ohne Runner. Wenn du bereit für automatisierte Tests oder Deployments bist, fügst du einen Runner hinzu.

Forgejo bringt eine integrierte Package-Registry mit, die standardmäßig aktiv ist. Du kannst eigene Pakete und Container-Images direkt in Forgejo speichern – ohne externe Registry wie Docker Hub oder npmjs.com.

Unterstützt werden unter anderem:

• Container/OCI (Docker-Images)
• npm (JavaScript/Node.js)
• PyPI (Python)
• Maven (Java)
• NuGet (.NET)
• Cargo (Rust)
• Composer (PHP)

Konkrete Nutzungshinweise und die passenden Befehle für jeden Pakettyp findest du im “Pakete”-Tab deines Nutzer- oder Organisations-Profils.

Ideal in Kombination mit Actions

Die Package-Registry spielt ihre Stärke besonders mit Forgejo Actions aus: Ein Workflow baut dein Paket oder Container-Image und pusht es direkt in deine eigene Registry – alles auf deiner Instanz, ohne externe Dienste.

Du kannst bestehende Repositories aus anderen Plattformen direkt nach Forgejo holen. Über das Plus-Symbol oben rechts → “Neue Migration” importierst du Repositories aus GitHub, GitLab oder Gitea – inklusive Issues, Pull Requests und Wiki, je nach Quelle. So ziehst du deine bestehenden Projekte ohne Umwege auf deine eigene Instanz um.

Forgejo unterstützt SSO über OpenID Connect (OIDC) und LDAP. Da du vollen Admin-Zugriff hast, kannst du eine Authentifizierungsquelle selbst einrichten:

1. Gehe zu Administration → Identität & Zugriff → Authentifizierungsquellen → Authentifizierungsquelle hinzufügen.
2. Wähle als Typ OAuth2 und als Anbieter OpenID Connect und trage Client-ID, Client-Secret und die OpenID-Connect-Auto-Discovery-URL (z. B. https://dein-idp.example.com/.well-known/openid-configuration) deines Identity Providers ein.
3. Optional kannst du festlegen, dass beim ersten SSO-Login automatisch ein Account angelegt wird.

Als Identity Provider empfehlen wir Authentik bei server.camp – so loggen sich deine Mitarbeitenden mit ihrem zentralen Konto ein, und Onboarding wie Offboarding laufen zentral.

Wir helfen bei der Einrichtung

Die Anbindung an einen Identity Provider erfordert ein paar Werte aus beiden Systemen. Wenn du dabei Unterstützung brauchst, hilft dir unser Support gerne weiter.

Jeder Nutzer kann unter Benutzereinstellungen → Sicherheit eine Zwei-Faktor-Authentifizierung aktivieren. Wir empfehlen 2FA für alle Nutzer – Pflicht insbesondere für den root-Account und weitere Administratoren.

Speichere Zugangsdaten, Tokens und API-Keys niemals im Code. Nutze für persönliche Geheimnisse einen Passwort-Manager wie Vaultwarden. Für Forgejo Actions hinterlegst du Secrets über die Secrets-Verwaltung in den Repository- bzw. Organisations-Einstellungen, sodass sie in Workflows verfügbar sind, ohne im Code sichtbar zu werden.

Verbinde Forgejo mit Mattermost über Webhooks (Repository-Einstellungen → Webhooks). So landen neue Pull Requests, Issue-Updates und Push-Ereignisse automatisch in einem Entwickler-Channel.

Verbinde Forgejo per OpenID Connect mit Authentik. Mitarbeitende loggen sich mit einem zentralen Konto ein, Onboarding und Offboarding werden zentral gesteuert.

Speichere Forgejo-Zugangsdaten, Access-Tokens und SSH-Schlüssel sicher in Vaultwarden.

Tipp: Nutze Issues nicht nur für Code-Aufgaben, sondern auch als Todo-Liste für Projekte. So hast du Aufgaben, Code und Dokumentation an einem Ort.

Falls du einen Runner als Add-on buchen möchtest, Fragen zur Rechteverwaltung hast oder SSO einrichten willst, erreichst du uns jederzeit unter support@server.camp. Wir helfen dir gerne!

Häufig gestellte Fragen zu Forgejo findest du auch auf unserer Produktseite von Forgejo. Die vollständige technische Dokumentation findest du in der offiziellen Forgejo-Dokumentation.