GitHub, Azure DevOps, Bitbucket — oder GitLab, Gitea, Forgejo?

Über die Wahl der Git-Plattform wird selten lange diskutiert. Meistens ist es eine Fortschreibung: Man hatte schon GitHub, das Team kennt es, also bleibt es. Für ein Werkzeug, das den vollständigen Quellcode, sämtliche Build-Geheimnisse und die Berechtigung zum Deployment in die Produktion enthält, ist das eine bemerkenswert beiläufige Entscheidung.

Denn die Git-Plattform ist nicht einfach eine Dateiablage. Sie ist der Ort, an dem das geistige Eigentum eines Unternehmens liegt, an dem Deploy-Schlüssel und API-Token gespeichert sind, und von dem aus CI-Pipelines mit Produktionsrechten laufen. Wer diese Plattform kontrolliert, kontrolliert im Zweifel die gesamte Software-Lieferkette.

Die drei großen: GitHub, Azure DevOps, Bitbucket

GitHub

Der Marktführer, seit 2018 bei Microsoft. Und die Stärken sind real, nicht bloß Gewohnheit:

• Das Ökosystem ist konkurrenzlos. GitHub Actions hat einen Marktplatz, in dem für praktisch jede Aufgabe eine fertige Action liegt. Jedes Werkzeug, jeder Cloud-Anbieter, jeder Scanner integriert zuerst mit GitHub.
• Netzwerkeffekt. Open-Source-Abhängigkeiten liegen dort. Issues melden, Patches beisteuern, Sicherheitshinweise verfolgen — all das passiert auf GitHub.
• Sicherheitsfunktionen. Dependabot, Secret Scanning, Code Scanning, Advisory-Datenbank. In dieser Integrationstiefe bietet das sonst niemand.
• Vertrautheit. Neue Entwickler brauchen keine Einarbeitung.

Die Kehrseite: Microsoft ist ein US-Konzern und unterliegt dem CLOUD Act. GitHub Enterprise Cloud bietet inzwischen Datenresidenz in der EU, und Microsoft hat mit der EU-Datengrenze viel investiert — beides mindert das Risiko, hebt es aber nicht auf. Datenresidenz regelt, wo Daten liegen, nicht, wer sie im Ernstfall herausgeben muss. Wer vollständige Kontrolle will, landet bei GitHub Enterprise Server, der selbst gehosteten Variante — die deutlich teurer ist und beim Ökosystem-Vorteil Abstriche macht.

Der zweite Punkt ist Abhängigkeit: Actions-Workflows sind GitHub-spezifisch. Wer hunderte Pipelines darin hat, migriert nicht an einem Wochenende.

Azure DevOps

Die Microsoft-Plattform aus der Zeit vor dem GitHub-Kauf: Repos, Pipelines, Boards, Artifacts, Test Plans — ein zusammenhängendes Paket.

• Stark, wenn die Microsoft-Landschaft schon steht. Entra ID, Azure-Deployments, Lizenzbündel: Das greift sauber ineinander.
• Boards sind ausgereift. Für Teams, die klassisch mit Sprints, Epics und Kapazitätsplanung arbeiten, ist die Projektsteuerung stärker als GitHub Projects.
• Azure DevOps Server existiert weiterhin als selbst gehostete Variante im eigenen Rechenzentrum.

Der wesentliche Vorbehalt ist strategisch: Microsoft investiert erkennbar in GitHub, nicht in Azure DevOps. Das Produkt wird gepflegt, aber neue Funktionen — insbesondere im KI-Bereich — erscheinen zuerst und teils ausschließlich bei GitHub. Wer heute neu beginnt, sollte diese Richtung einkalkulieren. Rechtlich gilt dasselbe wie bei GitHub: US-Konzern, CLOUD Act, EU-Datengrenze als Milderung, nicht als Auflösung.

Bitbucket

Atlassian, australisches Unternehmen mit starker US-Präsenz.

• Jira-Integration. Wer Jira und Confluence einsetzt, bekommt eine durchgehende Kette von Ticket zu Commit zu Deployment. Das ist der Hauptgrund, Bitbucket zu wählen — und ein guter.
• Bitbucket Pipelines ist solide, wenn auch weniger mächtig als Actions oder GitLab CI.

Die Nachteile sind deutlicher als bei den anderen beiden. Das Ökosystem ist kleiner, die Entwicklung wirkt weniger dynamisch, und Atlassian hat mit dem Ende der Server-Lizenzen viele Bestandskunden zum Umzug in die Cloud oder in die teurere Data-Center-Variante gedrängt — ein Vorgang, der Vertrauen gekostet hat. Datenresidenz in der EU ist verfügbar, ein EU-Anbieter ist Atlassian nicht.

Die selbst hostbaren: GitLab, Gitea, Forgejo

GitLab

Der vollständigste Gegenentwurf. GitLab Inc. ist zwar ein US-Unternehmen — entscheidend ist aber, dass die Software selbst betrieben werden kann, und die Community Edition ist quelloffen.

• Alles in einem Produkt. Repositories, CI/CD, Container-Registry, Paket-Registry, Issue-Tracking, Wiki, Security-Scanning, Umgebungen. Kein Zusammenstecken aus fünf Diensten.
• GitLab CI ist ausgezeichnet. Eine .gitlab-ci.yml, keine Marktplatz-Abhängigkeit, Runner überall betreibbar — auch im eigenen Cluster, mit direktem Zugriff auf interne Netze, ohne etwas nach außen zu öffnen.
• Selbst gehostet ohne Zugriff Dritter. Kein Auftragsverarbeiter, kein Drittlandtransfer. Die deutsche Verwaltungsplattform Open CoDE etwa setzt auf GitLab.
• Migrationspfad. Import aus GitHub und Bitbucket inklusive Issues und Pull Requests ist gut gelöst.

Die Nachteile sind ebenso real: GitLab ist schwergewichtig. Eine Produktionsinstanz mit Registry und Runnern braucht spürbar Ressourcen und regelmäßige Pflege — Upgrades sind versionsgebunden und wollen in der richtigen Reihenfolge gefahren werden. Und das Open-Core-Modell führt regelmäßig zu Enttäuschung: Manche Funktion, die man erwartet, steckt in einer kostenpflichtigen Stufe.

Gitea

Der schlanke Gegenpol: ein einzelnes Go-Binary, SQLite oder PostgreSQL dahinter, läuft auf einem kleinen Server.

• Minimaler Ressourcenbedarf. Eine Instanz für ein kleines Team läuft auf Hardware, auf der GitLab nicht startet.
• Schnelle Oberfläche, kurze Einarbeitung. Wer GitHub kennt, findet sich sofort zurecht.
• Gitea Actions ist weitgehend kompatibel zur Actions-Syntax — bestehende Workflows lassen sich häufig mit geringen Anpassungen übernehmen.

Was fehlt: die Tiefe. Kein integriertes Security-Scanning, schlankere Rechteverwaltung, weniger Automatisierung rund um Releases und Umgebungen. Und ein Governance-Vorbehalt: Die Überführung des Projekts in eine kommerzielle Gesellschaft hat 2022 Teile der Community verstört — genau daraus entstand Forgejo.

Forgejo

Der Fork von Gitea, getragen von Codeberg e.V., einem gemeinnützigen Verein mit Sitz in Berlin. Technisch nah an Gitea, im Kern aber eine andere Antwort auf die Frage, wem das Projekt gehört.

• Governance in gemeinnütziger Hand, nach deutschem Vereinsrecht. Keine Firma, die Lizenzbedingungen ändern oder verkauft werden kann. Für die Souveränitätsfrage ist das der stärkste Punkt im ganzen Feld: Nicht nur der Betrieb liegt im eigenen Haus, auch die Zukunft des Projekts hängt nicht an einer Unternehmensentscheidung.
• Copyleft-Lizenz. Bewusst so gewählt, damit Verbesserungen zurückfließen müssen.
• Forgejo Actions analog zu Gitea, mit eigenem Runner.
• Genauso schlank wie Gitea.

Der Preis: ein kleineres Projekt mit weniger Ressourcen als GitLab oder GitHub, ein deutlich dünneres Ökosystem an Integrationen und kein kommerzieller Support in der Breite, wie ihn große Organisationen einkaufen wollen. Für Einrichtungen, denen Unabhängigkeit wichtiger ist als Funktionsfülle, ist Forgejo trotzdem die konsequenteste Wahl — Codeberg selbst betreibt damit eine öffentliche Instanz.

Im Überblick

Was die Souveränitätsfrage konkret bedeutet

Sie zerfällt in drei Ebenen, die häufig vermischt werden:

Wo liegen die Daten? Die einfachste Ebene, und die, auf die Anbieter mit Datenresidenz-Angeboten antworten. Wichtig, aber allein nicht ausreichend.

Wer hat rechtlichen Zugriff? Ein US-Konzern unterliegt dem CLOUD Act — unabhängig davon, in welchem Rechenzentrum die Daten physisch liegen. Diese Ebene lässt sich durch Serverstandorte nicht auflösen, nur durch die Wahl des Betreibers.

Wer bestimmt über die Zukunft? Die am häufigsten übersehene Ebene. Lizenzmodelle ändern sich, Produkte werden eingestellt, Preise steigen sprunghaft, Bestandskunden werden zum Umzug gedrängt. Wer die Software selbst betreibt und quelloffen einsetzt, kann eine unerwünschte Entwicklung aussitzen. Wer in einer proprietären Cloud sitzt, kann es nicht.

Für die meisten Unternehmen ist die dritte Ebene die praktisch relevanteste — sie trifft ein, ohne dass eine Behörde je etwas anfordert.

Eine Empfehlung nach Zuschnitt

Kleines Team, wenig Betriebskapazität, kein besonderer Schutzbedarf: GitHub. Der Netzwerkeffekt ist ein echter Vorteil, und eine schlecht gepflegte eigene Instanz ist schlechter als eine gut betriebene fremde.

Mittelstand mit eigener IT und Datenschutzanspruch: GitLab selbst gehostet. Der Aufwand ist beherrschbar, der Funktionsumfang deckt alles ab, und die Migration von GitHub oder Bitbucket ist ein gelöster Vorgang. Das ist der häufigste sinnvolle Weg — und der, den wir selbst gehen: Unsere Repositories liegen auf einer eigenen GitLab-Instanz, einzelne Projekte bewusst zusätzlich auf GitHub.

Kleines Team mit hohem Souveränitätsanspruch: Forgejo oder Gitea. Ein kleiner Server genügt, die Pflege ist überschaubar.

Öffentliche Hand, Bildung, Gesundheitswesen, Vereine: Forgejo. Gemeinnützige Trägerschaft in Deutschland, Copyleft, keine Firma, die verkauft werden kann.

Bestehende Atlassian-Landschaft: Bitbucket ist vertretbar, solange Jira zentral bleibt. Steht ohnehin ein Wechsel an, sollte er ganz erfolgen.

Tiefe Microsoft-Integration mit klassischer Projektsteuerung: Azure DevOps — mit dem Wissen, dass die strategische Zukunft bei GitHub liegt.

Zum Umzug

Ein verbreiteter Irrtum ist, ein Plattformwechsel sei ein git push an eine neue Adresse. Der Quellcode ist tatsächlich trivial portierbar — das ist der Sinn eines verteilten Versionskontrollsystems. Alles andere ist es nicht:

• Issues und Pull Requests lassen sich importieren, aber selten vollständig samt Kommentaren, Verweisen und Zeitstempeln.
• CI-Pipelines müssen neu geschrieben werden. Actions-Workflows nach GitLab CI zu übertragen ist Handarbeit; Gitea und Forgejo mildern das durch ihre Actions-Kompatibilität.
• Integrationen — Deploy-Schlüssel, Webhooks, Statusprüfungen, Abhängigkeiten zu Ticketsystem und Chat — sind der eigentliche Aufwand.
• Gewohnheiten wiegen schwerer als erwartet. Ein Team, das jahrelang mit einer Oberfläche gearbeitet hat, verliert für einige Wochen Tempo.

Praktikabel ist ein schrittweiser Weg: neue Projekte auf der neuen Plattform beginnen, bestehende bei ohnehin anstehenden Überarbeitungen mitnehmen, den Rest gespiegelt lassen. Ein Stichtagsumzug über alle Repositories hinweg ist selten nötig und meist der teuerste Weg.

Fazit

Es gibt keine allgemein richtige Antwort — aber es gibt eine falsche Vorgehensweise, nämlich diese Entscheidung gar nicht zu treffen. Die Git-Plattform enthält den Quellcode, die Geheimnisse und die Deployment-Rechte eines Unternehmens. Wer sie bewusst wählt, kauft sich Handlungsfähigkeit für den Tag, an dem sich Lizenzmodell, Preis oder Rechtslage ändern.

Für den Mittelstand ist selbst gehostetes GitLab meist der beste Ausgleich zwischen Funktionsumfang und Unabhängigkeit. Für alle, denen Trägerschaft und Lizenz wichtiger sind als Funktionsfülle, ist Forgejo derzeit die klarste Antwort im europäischen Feld.

Wir betreiben GitLab-Instanzen für Kunden, migrieren aus GitHub und Bitbucket und bauen die CI/CD-Strecken dazu neu auf. Sprechen Sie uns an.