Git im kleinen Team — Gitea als eigene Zentrale einrichten

Warum eigenes Git-Hosting für kleine Teams

Für Open-Source-Projekte ist GitHub unschlagbar. Für interne Projekte sieht die Rechnung anders aus: private Repositories, Kundencode, vielleicht Zugangsdaten in der Konfiguration — das alles liegt dann auf fremden Servern. Gitea bringt dieselbe Grundfunktion auf einen Server, den ihr kontrolliert, und läuft dabei sparsam genug für kleine Hardware.

Organisationen statt persönlicher Repos

Der häufigste Anfängerfehler: Alle Repositories liegen unter dem persönlichen Konto des Gründers. Verlässt der das Team, hängt daran plötzlich die halbe Firma. Lege stattdessen von Anfang an eine Organisation an und die Repositories darunter. Personen kommen und gehen, die Organisation bleibt.

Rechte abstufen

Gitea kennt Teams innerhalb einer Organisation. Eine Aufteilung, die sich für kleine Gruppen bewährt:

• Owner — zwei Personen, nie nur eine. Wer allein Owner ist, blockiert das Team im Krankheitsfall
• Entwickler — darf pushen und Pull Requests eröffnen
• Lesend — für Praktikanten, externe Reviewer oder die Buchhaltung, die nur ins Wiki schaut

Ein Workflow ohne Zeremonie

In einem Team von zwei bis fünf Leuten braucht es keine ausgefeilte Branch-Strategie. Was reicht:

1. main ist immer lauffähig — von hier wird ausgeliefert
2. Jede Änderung passiert in einem eigenen Branch mit sprechendem Namen
3. Zusammengeführt wird über einen Pull Request, den jemand anderes kurz anschaut
4. Nach dem Merge wird der Branch gelöscht

Der Review muss nicht förmlich sein. Es geht nicht um Kontrolle, sondern darum, dass mindestens zwei Personen wissen, was sich geändert hat.

main schützen

Aktiviere für main eine Branch-Protection: kein direkter Push, Merge nur über Pull Request. Das verhindert die klassische Situation, in der jemand spätabends versehentlich direkt auf den Hauptzweig pusht und niemand nachvollziehen kann, was passiert ist.

Was ins Repository gehört — und was nicht

Keine Passwörter, keine API-Schlüssel, keine Zugangsdaten. Auch nicht in einem privaten Repository, denn die Git-Historie vergisst nichts: Ein einmal committetes Passwort bleibt in der Historie, selbst wenn du es in der nächsten Version löschst. Nutze stattdessen eine .env-Datei, die per .gitignore ausgeschlossen ist, und lege eine .env.example ohne echte Werte daneben.

Sichern nicht vergessen

Ja, jeder Entwickler hat eine vollständige Kopie der Historie — aber Issues, Pull Requests, Wiki und Benutzerkonten stecken in der Datenbank, nicht im Repository. Sichere sie regelmäßig mit, sonst überlebt nur der Code und alles drumherum ist weg.