GitHub-Alternativen 2026: Welche Plattform passt zum Team?

GitLab ist der stärkste umfassende Ersatz für GitHub. Wer GitHub-Alternativen selbst betreiben möchte, sollte zuerst Gitea prüfen. Diese 7 Alternativen teilen sich in verwaltete Dienste und selbst betriebene Software. Entscheidend ist aber, was zusammen mit dem Code umziehen muss: Reviews, Issues, CI/CD und Zugriffsregeln.

Am 5. November 2026 anhand der aktuellen Anbieterseiten überprüft. Dieser Vergleich stützt sich auf Dokumentation und Preise; praktische Migrationstests wurden nicht durchgeführt. Verfügbarkeit bedeutet, dass der Anbieter derzeit Registrierung, Kauf oder Installation ermöglicht. Dafür wurde weder ein Konto angelegt noch ein Vertrag genehmigt.

GitHub-Alternativen im Überblick

Zuerst kommt das Betriebsmodell, dann der Anbieter. Bei einem verwalteten Dienst betreibt der Anbieter die Codehosting-Plattform. Beim Eigenbetrieb liegen Installation, Backups und Wiederherstellung in der eigenen Verantwortung. Ein selbst betriebener CI-Runner – der Rechner, der Build-Jobs ausführt – macht einen Codehost in der Cloud noch nicht zu einer selbst betriebenen Plattform.

Die Preise markieren den Einstieg und stehen nicht für gleichwertige Pakete. Die Preislinks in den einzelnen Abschnitten führen zu den Bedingungen des jeweiligen Anbieters. Eine kostenlose Softwarelizenz finanziert keinen Server. Ein Repository-Abo umfasst auch nicht zwangsläufig einen KI-Assistenten, eine Aufgabenverwaltung oder unbegrenzte Build-Kapazität.

Vor einem Wechsel allein aus Kostengründen lohnt der Abgleich mit GitHubs aktueller Preisseite und unserer Aufschlüsselung der GitHub-Preise. Es sollte schriftlich feststehen, welche fehlende oder unpassende Funktion den Wechsel erzwingt. Sonst verdeckt ein niedrigerer Nutzerpreis womöglich höhere Migrations- und Wartungskosten.

Verwaltete Alternativen zu GitHub

Verwaltetes Hosting ist die naheliegende Wahl, wenn intern niemand für die Verfügbarkeit der Entwicklungsinfrastruktur zuständig ist. Das Entwicklungsteam kann weiterhin Repository-Berechtigungen steuern und eigene Build-Rechner betreiben; die Hosting-Anwendung wartet der Anbieter. Innerhalb dieser Gruppe ist vor allem zwischen umfassenden Entwicklungsplattformen und Diensten für eine bestimmte Community oder Cloud zu unterscheiden.

GitLab: der stärkste Ersatz für die gesamte Plattform

GitLab verbindet Repositorys, Aufgabenverwaltung, Merge Requests und CI/CD – also die Automatisierung zum Bauen, Testen und Ausliefern von Software. Für Unternehmen, die nach dem Abschied von GitHub Code-Reviews und Auslieferung zusammenhalten möchten, ist es der beste erste Prüfkandidat. Ein Produktteam mit Anwendungscode, Backlog und Release-Pipeline kann seinen gesamten Arbeitsablauf an einem Ziel erproben. Die Grenze: Es bleibt eine Plattformmigration. Vertraute Konzepte garantieren keine identischen Berechtigungen, Automatisierungen oder historischen Diskussionen.

Besonders geeignet für: Entwicklungsverantwortliche, die mehrere zusammenhängende GitHub-Abläufe ersetzen möchten.
Besonderheit: Ein GitHub-Importer, der neben Repository-Daten auch Metadaten der Zusammenarbeit übernimmt.
Preise: Free $0; Premium ab $29/Nutzer/Monat bei jährlicher Abrechnung laut GitLab-Preisseite.
Kostenlos testen: Neben dem dauerhaften Free-Tarif bietet der Hersteller eine Testversion für Bezahltarife.

CI/CD, Issues und Reviews: Alle gehören zur Plattform. Merge Requests sind GitLabs Entsprechung zu Pull Requests: Änderungsvorschläge, die vor dem Zusammenführen besprochen werden. GitLab.com Free nennt eine Grenze von 5 Nutzern je übergeordneter Gruppe und 400 Rechenminuten pro Monat. Eine solche Gruppe ist der organisatorische Rahmen für Projekte und Mitglieder. Diese Hosting-Kontingente gelten nicht einfach für eine selbst verwaltete Installation und bedeuten keine dedizierte Rechenkapazität.

KI-Programmierassistent: GitLab Duo ist das KI-Angebot des Herstellers. Es umfasst Unterstützung über IDE-Erweiterungen und die GitLab-Oberfläche sowie Agenten und automatisierte Abläufe. Eine IDE ist die Entwicklungsumgebung, in der Code geschrieben und debuggt wird. Verfügbarkeit und Nutzung hängen vom Tarif, der Bereitstellungsform und GitLab Credits ab. Ein kostenloses Hosting-Konto verspricht keinen kostenlosen Zugang zu sämtlichen Duo-Funktionen. Die Duo-Dokumentation beschreibt außerdem den Betrieb unterstützter Modelle und eines KI-Gateways; dafür ist eine eigene Prüfung des Bereitstellungsmodells nötig.

Import aus GitHub: Laut Dokumentation zum GitHub-Importer werden Repository-Daten, Issues, Pull Requests, Kommentare und weitere Projektmetadaten unterstützt. GitHub-Organisationen oder -Gruppen werden nicht als Organisationen oder Gruppen migriert. Markdown-Anhänge sind optional importierbar. Wird die Quelle zu früh gelöscht, können historische Links ins Leere führen. Das wird relevant, wenn ein altes Störungsticket den einzigen Screenshot enthält, der einen Produktionsausfall erklärt.

GitLab vs GitHub: Welche Anforderung entscheidet den Vergleich?

GitLab lohnt sich, wenn die Bündelung von Auslieferung und Zusammenarbeit eine Änderung der Arbeitsabläufe rechtfertigt. GitHub bleibt sinnvoll, wenn sich das Hauptproblem durch Zugriffsrichtlinien oder Abrechnungskontrollen lösen lässt und der Release-Prozess stark von vorhandenen Integrationen abhängt. Wer wegen eines unerwünschten Assistenten wechselt, ohne die Aktivierung von Duo zu prüfen, löst die eigentliche Richtlinienfrage nicht.

Für einen Pilotversuch eignet sich ein Repository mit genügend Historie, um Probleme sichtbar zu machen: ein abgeschlossenes Review mit Kommentaren, ein Issue-Anhang und ein aktiver Release-Prozess. Ein fast leeres Repository beweist wenig. Eine Person aus der Entwicklung und die für Release-Freigaben zuständige Person sollten das Ergebnis gemeinsam prüfen; ihnen fallen unterschiedliche Fehler auf.

1. 1

   Ziel und begrenzten Importzugriff vorbereiten

   Die Zielgruppe anlegen und sicherstellen, dass der importierende Nutzer die erforderliche Maintainer- oder Owner-Rolle besitzt. Bei selbst betriebenem GitLab die GitHub-Importquelle aktivieren. Eine freigegebene OAuth-Verbindung oder die dokumentierte Token-Methode verwenden und den Zugriff auf die Migration begrenzen.

2. 2

   GitHub-Importer ausführen

   Create new, dann New project/repository, Import project und GitHub auswählen. Den Zugriff autorisieren, das Repository wählen und vor dem Start den Ziel-Namespace sowie die optionalen Einstellungen für Anhänge prüfen.

3. 3

   Historie der Zusammenarbeit gesondert abnehmen

   Branches, Tags, Issues, Review-Kommentare und Anhänge mit der Quelle vergleichen. Identitäten und Zugriffe gezielt prüfen. GitHub verfügbar halten, bis Abweichungen geklärt sind. Ein abgeschlossener Import belegt nicht, dass jeder historische Link funktioniert.

4. 4

   Release-Prozess vor der Umschaltung nachbauen

   Ziel-Pipeline, Zugangsdaten und Release-Freigaben einrichten. Einen Release und ein Rollback proben. Anschließend das neue maßgebliche Repository festlegen und temporäre Migrationszugriffe entfernen. GitLabs Repository-Spiegelung synchronisiert spätere Änderungen an GitHub-Pull-Requests nicht.

Bitbucket Cloud: sinnvoll, wenn Jira die Arbeit bereits organisiert

Bitbucket Cloud ist Atlassians verwalteter Dienst für Repositorys und Reviews, ergänzt durch Pipelines für Builds und Deployments. Er passt zu Unternehmen, deren Entwicklung bereits in Jira plant und Repository-Aktivitäten mit diesen Vorgängen verknüpfen möchte. Der praktische Nutzen: Eine Änderung bleibt mit der Aufgabe verbunden, die sie begründet. Die Grenze liegt bei der Aufgabenverwaltung: Die nativen Issues und Wikis von Bitbucket wurden eingestellt. Wer neben jedem Repository einen kleinen eigenständigen Tracker sucht, ist hier nicht mehr richtig.

Besonders geeignet für: Teams mit etabliertem Jira-Arbeitsablauf.
Besonderheit: Repository- und Pipeline-Aktivitäten sind mit der Aufgabenverwaltung verbunden.
Preise: Kostenlos für bis zu 5 Nutzer; Standard ab $3.65/Nutzer/Monat laut Bitbucket-Preisseite.
Kostenlos testen: Testversionen für Standard und Premium sind verfügbar.

CI/CD, Issues und Reviews: Pipelines ist integriert; der Free-Tarif nennt 50 Build-Minuten pro Monat. Pull Requests und Reviewer werden unterstützt, verbindliche Merge-Prüfungen sind dagegen eine Frage des Bezahltarifs. Für Issues ist Jira oder ein anderer Tracker einzuplanen. Atlassians Mitteilung zur Einstellung von Issues und Wikis bestätigt deren Entfernung am 20. August 2026.

KI-Programmierassistent: Atlassians Angebot heißt Rovo Dev und umfasst Programmierhilfe und Code-Reviews. Die Zusammenstellung des Angebots ändert sich jedoch. Laut Mitteilung zum Übergang von Rovo Dev läuft das eigenständige Produkt aus, Code Reviewer wandert in berechtigte Jira- und Teamwork-Collection-Abos, und die CLI entwickelt sich zur Rovo CLI weiter. Ein endgültiges Datum für das Ende des eigenständigen Produkts war auf der geprüften Seite nicht bestätigt. Maßgeblich ist die konkret für die Organisation geltende Nutzungsberechtigung. Ein Bitbucket-Nutzerplatz sollte nicht so kalkuliert werden, als umfasse er automatisch einen unveränderten eigenständigen Assistenten.

Import aus GitHub: Über Create, Repository und anschließend Import repository die GitHub-Repository-URL und nötigenfalls Zugangsdaten angeben. Atlassian dokumentiert einen Repository-Importer, keinen vollständigen Transfer von GitHub-Issues, Reviews und Organisationsrichtlinien. Dafür sind eigene Arbeitsschritte nötig.

Für ein Team mit Jira kann die Überführung von GitHub-Issues in das vorhandene Projekt eine sinnvolle Aufräumaktion sein. Für ein kleines Unternehmen, das bisher nur GitHub Issues nutzt, entsteht womöglich ein zusätzlich zu verwaltendes System. Bevor der Nutzerpreis als Ersparnis verbucht wird, muss feststehen, wer Issue-Links und historische Verweise pflegt.

Urteil: Bitbucket überzeugt durch den Atlassian-Arbeitsablauf. Ohne Interesse an Jira verliert dieser Vorteil deutlich an Gewicht.

Azure DevOps Services: stark bei Arbeitsplanung und Microsoft-geprägter Auslieferung

Azure DevOps Services ist Microsofts gehostete Suite aus Repos, Boards und Pipelines. Sie passt, wenn Vorgänge, Release-Prozesse und Organisationsverwaltung wichtiger sind als GitHubs soziale Funktionen. Ein Unternehmen mit internen Anwendungen kann Aufgabe, Codeänderung und Deployment-Abstimmung innerhalb der Suite halten. Die Grenze liegt im Funktionsumfang: Ein Wechsel zu Azure Repos erhält nicht jede GitHub-spezifische Funktion, auch nicht jede Funktion unter dem Namen Copilot.

Besonders geeignet für: Organisationen, die Planung und Auslieferungsinfrastruktur zusammenführen möchten.
Besonderheit: Vorgänge in Boards sind mit Repository- und Pipeline-Arbeit verknüpft.
Preise: Basic umfasst die ersten 5 Nutzer kostenlos, danach $6/zusätzlichem Nutzer/Monat laut Azure-DevOps-Preisseite.
Kostenlos testen: Das kostenlose Basic-Kontingent gilt dauerhaft; es ist vom separaten Testangebot für Test Plans zu unterscheiden.

CI/CD, Issues und Reviews: Azure Pipelines liefert CI/CD, Boards verwaltet Vorgänge und Repos bietet Pull Requests. Das beworbene kostenlose Kontingent für gehostete Pipelines umfasst einen parallelen Job mit 1,800 Minuten pro Monat. Ein paralleler Job bedeutet die Kapazität, jeweils einen Job auszuführen; nicht alle wartenden Builds starten gleichzeitig. Laut aktueller Dokumentation zu parallelen Jobs schaltet die Verknüpfung eines gültigen Azure-Abonnements das Freikontingent für private Projekte frei.

KI-Programmierassistent: GitHub Copilot Code Review für Azure Repos befindet sich in der öffentlichen Vorschau. Es bietet Organisations- und Repository-Kontrollen und wird über ein verknüpftes Azure-Abonnement abgerechnet. Der Dienst kann geänderten Code vor dem menschlichen Review kommentieren. Die separate Übergabe aus Azure Boards, bei der Copilot einen Vorgang implementieren soll, benötigt hingegen weiterhin ein GitHub-Repository. Microsofts Dokumentation zu Reviews in Azure Repos und die Voraussetzungen der Boards-Programmierintegration beschreiben unterschiedliche Integrationen. Weder „Copilot funktioniert“ noch „Copilot ist nicht verfügbar“ ist für diese Kaufentscheidung präzise genug.

Import aus GitHub: Der Repository-Import benötigt die Git-URL der Quelle und die erforderliche Authentifizierung. Microsofts Anleitung zum Git-Import behandelt den Import in ein neues oder leeres Ziel-Repository. Large File Storage, kurz LFS, speichert große Binärdateien außerhalb gewöhnlicher Git-Objekte. Deren Zeiger können mit dem Repository ankommen, während die eigentlichen Dateien noch übertragen werden müssen. GitHub-Issues und die Pull-Request-Historie sind gesondert einzuplanen.

Ein aussagekräftiger Pilot nutzt einen bestehenden Dienst mit Build-Artefakt und Deployment-Freigabe, keine reine Quellcodebibliothek. Die Release-Verantwortlichen sollten eine vorgeschlagene Änderung vom Boards-Vorgang bis zum abgeschlossenen Deployment verfolgen. Ist dieser Weg klarer als bisher, bringt die Suite einen Nutzen. Müssen Entwickler nun mehrere Tracker manuell aktualisieren, hat die Migration ein Abstimmungsproblem geschaffen.

Codeberg: hervorragend für freie Software, ungeeignet für ein privates Produktunternehmen

Codeberg ist eine gemeinnützige gehostete Entwicklungsplattform für Code und Zusammenarbeit auf Basis von Forgejo. Sie eignet sich besonders für öffentliche Bibliotheken oder Community-Projekte, deren Mitwirkende Wert auf die Grundsätze freier Software legen. Die Grenze ist die Zulässigkeit: Codeberg ist kein allgemeiner kommerzieller Hosting-Dienst für privaten SaaS-Code. Auftrag und Ressourcenregeln des Dienstes gehören zur Produktentscheidung und sollten vor der Migration geklärt sein.

Besonders geeignet für: Freie und Open-Source-Projekte, die zum gemeinnützigen Auftrag passen.
Besonderheit: Community-orientiertes Hosting mit einer ausdrücklichen Haltung zum KI-Training.
Preise: $0 für zulässige Nutzung, finanziert durch freiwillige Spenden und Mitgliedschaften laut Codeberg-FAQ.
Kostenlos testen: Zulässiges Hosting ist dauerhaft möglich; einen kommerziellen Weg von der Testversion zum Upgrade gibt es nicht.

CI/CD, Issues und Reviews: Issues und Pull Requests sind verfügbar. Für Woodpecker CI sind eine Zugangsanfrage und manuelle Freigabe nötig. Forgejo Actions kann selbst betriebene Runner nutzen; ein begrenztes gehostetes Angebot befindet sich in der offenen Alpha. Die CI-Dokumentation nennt diese Bedingungen ausdrücklich. „CI verfügbar“ bedeutet nicht, dass jedes neue Projekt sofort eine verwaltete Runner-Flotte erhält.

KI-Programmierassistent: Auf den geprüften Produktseiten wird kein eigener Programmierassistent beworben. Codeberg erklärt, gehostete Projekt- oder Nutzerdaten nicht zum Training generativer KI zu verwenden, und schränkt stark LLM-generierte Projekte ein. Die veröffentlichte Erläuterung der Richtlinie unterscheidet außerdem aktive etablierte Communities und gelegentliche generierte Beiträge von Projekten, die überwiegend durch Agenten erstellt oder gepflegt werden. Daraus sollte nicht die pauschale Behauptung werden, jeder frühere KI-Beitrag disqualifiziere ein Projekt automatisch.

Import aus GitHub: Im Plus-Menü New Migration und GitHub wählen, den erforderlichen Zugriffstoken angeben und die zu übertragenden Metadaten auswählen. Codebergs Migrationsanleitung behandelt Issues, Labels, Releases, Meilensteine und weitere unterstützte Metadaten. Die allgemeine Git-Quelle überträgt Repository-Inhalte ohne diese zusätzlichen Metadaten. Den Migrationstoken nach der Abnahme widerrufen.

Bei einer von Freiwilligen gepflegten öffentlichen Abhängigkeit ist der Einstieg neuer Mitwirkender genauso wichtig wie der Import. Neue Beitragsregeln veröffentlichen, den Ort der Reviews erklären und den maßgeblichen Projektstandort eindeutig kennzeichnen. Zieht nur das Repository um, während die Gewohnheiten der Community gleich bleiben, müssen Maintainer weiterhin zwei Orte überwachen.

Codeberg betreibt die meisten Dienste auf eigener Hardware in Berlin. Die FAQ nennt für bestimmte Aufgaben jedoch weitere Standorte und Anbieter. Das ist eine nützliche Infrastrukturinformation, aber keine vertragliche Zusage, dass jede Datenkopie in Deutschland bleibt. Ein Unternehmen mit proprietärer Software und strengen Standortvorgaben sollte eine eigene Hosting-Bereitstellung prüfen, statt sich von einer Spende eine Ausnahme zu versprechen.

SourceHut: E-Mail-Arbeitsablauf und KI-Regeln bewusst wählen

SourceHut ist eine Open-Source-Entwicklungssuite rund um Git, Mailinglisten, Tickets und Builds. Sie passt zu Maintainern, die Patches per E-Mail prüfen und ergänzende Webtools nutzen möchten, statt GitHubs Pull-Request-Erlebnis nachzubilden. Für ein Projekt, das Beiträge bereits auf einer Mailingliste bespricht, gibt es einen klaren Anlass zur Prüfung. Grenzen setzen die Umstellung des Arbeitsablaufs, der öffentliche Alpha-Status und eine KI-Richtlinie des gehosteten Dienstes, die viele heutige Programmierpraktiken ausschließt.

Besonders geeignet für: Projekte, die Patch-Reviews per E-Mail ausdrücklich bevorzugen.
Besonderheit: Gemeinsame Entwicklung auf Basis von Mailinglisten.
Preise: Hosting-Abos ab $4/Monat vor anfallenden Steuern; alle Bezahltarife bieten denselben Dienstzugang laut SourceHut-Preisseite.
Kostenlos testen: Bei vielen Diensten ist die Zahlung während der Alpha derzeit freiwillig. Builds erfordern eine Zahlung; allein für die Mitarbeit müssen Beitragende nicht bezahlen.

CI/CD, Issues und Reviews: Die Suite enthält builds.sr.ht für CI, todo.sr.ht für Tickets und Patch-Reviews über Mailinglisten mit ergänzenden Webtools. Ein Patch ist ein zur Prüfung versandter Änderungsvorschlag. Maintainer besprechen ihn und übernehmen eine akzeptierte Fassung. Die Auslieferungsautomatisierung muss weiterhin für das eigene Projekt eingerichtet werden. Das Abo liefert kein fertiges Release-System.

KI-Programmierassistent: SourceHut wirbt ausdrücklich damit, keine KI-Funktionen anzubieten. Die Änderung der KI-Richtlinie ging für neue Projekte ab dem 10. September 2026 weiter: Originalinhalte, die mit generativer KI geschrieben oder unterstützt wurden, sowie Software, die generative KI ermöglicht, sind auf dem gehosteten Dienst verboten. Dabei gelten die dort genannten Auslegungen und Ausnahmen. Die Erläuterung erlaubt private Analysen oder Reviews, sofern das Originalmaterial anschließend selbst verfasst wird. Ein Team, das regelmäßig von Assistenten geschriebenen Code einreicht, sollte diesen gehosteten Dienst nicht wählen.

Import aus GitHub: Das Handbuch des Git-Dienstes beschreibt, wie extern gehosteter Quellcode geklont und zu git.sr.ht hinzugefügt wird. Das ist ein Weg zur Git-Übertragung. Es belegt weder, dass GitHub-Pull-Request-Diskussionen zu gleichwertigen Mailinglisten-Threads werden, noch dass Issues automatisch im Ticket-Tracker landen. Diese Inhalte separat erfassen und festlegen, was als lesbares Archiv erhalten bleiben muss.

Vor dem Umzug eines Unternehmensprojekts sollte eine neu hinzukommende Person die vorgesehenen Beitragsregeln durchlaufen. Kann sie einen Patch einreichen, auf Rückmeldungen reagieren und die akzeptierte Fassung finden? Ein für erfahrene Maintainer übersichtlicher Ablauf kann für alle anderen Einarbeitungsaufwand bedeuten. Das kann sich lohnen, sollte aber eine bewusste Betriebsentscheidung sein.

Die Software lässt sich auch selbst betreiben. Das ist von der Zulässigkeit auf SourceHuts gehostetem Dienst zu trennen: Der Betrieb auf eigener verwalteter Infrastruktur ist ein anderes Bereitstellungs- und Verantwortungsmodell.

AWS CodeCommit: wieder verfügbar, aber enger zugeschnitten

AWS CodeCommit ist ein verwalteter Dienst für private Git-Repositorys. Er richtet sich an Organisationen, die Repository-Zugriffe innerhalb ihres AWS-Betriebsmodells halten möchten. Auf die Auswahlliste gehört er, wenn AWS-Identitätsberechtigungen und Netzwerkgrenzen zentrale Anforderungen sind. Die Mitteilung zur Wiederöffnung bestätigt ausdrücklich, dass AWS wieder Neukunden annimmt. Einige ältere AWS-Seitenbanner behaupten noch das Gegenteil. Die Wiederöffnungsmitteilung und der aktuelle Dokumentationsverlauf lösen diesen früheren Aufnahmestopp ab.

Besonders geeignet für: AWS-geprägte Organisationen mit konkreten Vorgaben zur Abgrenzung ihrer Repositorys.
Besonderheit: Repository-Zugriff ist mit AWS-Identitäts- und Infrastrukturdiensten verbunden.
Preise: Ein Freikontingent ist verfügbar; kostenpflichtige Nutzung kostet $1/aktivem Nutzer/Monat zuzüglich anfallendem Mehrverbrauch laut CodeCommit-Preis-FAQ.
Kostenlos testen: Der Anbieter veröffentlicht ein dauerhaftes Kontingent, keinen befristeten Test der gesamten Plattform.

CI/CD, Issues und Reviews: CodeCommit unterstützt Pull Requests und gemeinsame Reviews. Build- und Auslieferungsautomatisierung kommen über separate Dienste wie AWS CodeBuild und AWS CodePipeline hinzu. Ein Issue-Tracker ist gesondert einzuplanen. Es handelt sich um eine Zusammenstellung von Diensten. Verglichen werden sollten deshalb der resultierende Arbeitsablauf und seine Kosten, nicht Repository-Hosting als vermeintliches Komplettabo für die Entwicklung.

KI-Programmierassistent: AWS bietet Amazon Q Developer zur Programmierunterstützung an. Es ist ein separates Angebot und kein Beleg dafür, dass der Kauf von CodeCommit jedem Repository oder Review automatisch einen integrierten Assistenten hinzufügt. Repository-Auswahl und Nutzungsberechtigung für den Assistenten getrennt bewerten.

Import aus GitHub: AWS dokumentiert eine Git-Repository-Migration: das vorhandene Git-Repository beschaffen, das CodeCommit-Ziel anlegen und den Code übertragen. Das importiert keine GitHub-Issues, Pull-Request-Unterhaltungen oder Actions-Workflows. Diese Systeme sind separat zu ersetzen oder zu erhalten.

Ein sinnvoller Pilot belegt Zugriff und Auslieferung innerhalb der vorgesehenen AWS-Konfiguration. Kann die vorgesehene Entwickleridentität das Repository abrufen? Erhält die Build-Identität nur den erforderlichen Quellcodezugriff? Funktioniert der Release mit den vorgesehenen Berechtigungen? Diese Fragen erklären, warum ein Team CodeCommit wählen könnte, obwohl eine andere Plattform eine einheitlichere Oberfläche bietet.

Urteil: CodeCommit einbeziehen, wenn die AWS-Integration den Wechsel begründet. Wer als Gründer einfach einen vertrauten GitHub-Ersatz sucht, sollte zuerst GitLab oder Gitea prüfen.

Software im Eigenbetrieb: Gitea, GitLab und der Betriebsaufwand

Eigenbetrieb passt besonders dann, wenn Infrastrukturwahl, Anwendungsverwaltung und Wiederherstellung unter eigener Kontrolle liegen müssen. Damit gehört auch ein Ausfall zur eigenen Verantwortung. Entscheidend ist, ob jemand den Dienst nach einem Festplatten-, Datenbank- oder Upgrade-Fehler wiederherstellen kann, nicht ob die Installation einfach aussieht.

Gitea: der erste Kandidat für den Eigenbetrieb

Gitea ist eine Open-Source-Entwicklungsplattform für Repositorys, Issues, Pull Requests und Automatisierung. Für eine kleine Entwicklungsorganisation, die ihre Codeplattform selbst betreiben möchte, ohne automatisch eine umfassendere Suite einzuführen, ist es der beste Ausgangspunkt. Ein Team für interne Tools kann Reviews und Aufgaben bei seinen Repositorys halten und den Betriebsort selbst wählen. Die Grenze ist die Betriebsverantwortung: Die kostenlose Lizenz liefert weder Backups und Monitoring noch Runner-Isolation oder Personal für die Wiederherstellung.

Besonders geeignet für: Teams, die eine selbst verwaltete Entwicklungsplattform wünschen und deren Betrieb übernehmen können.
Besonderheit: Repositorys, Issues, Pull Requests und Actions im Open-Source-Produkt.
Preise: Open Source kostet $0 unter der MIT-Lizenz; Hosting und Administration kommen hinzu, siehe Gitea-Preisseite.
Kostenlos testen: Open-Source-Nutzung ist dauerhaft möglich; daneben bietet der Hersteller kommerzielle Testversionen.

CI/CD, Issues und Reviews: Gitea enthält Issues und Pull Requests sowie Gitea Actions für CI/CD. Die Actions-Dokumentation beschreibt eine weitgehende Kompatibilität mit GitHub Actions und ein separates Runner-Programm. „Weitgehend“ ist entscheidend. Eine vertraute Workflow-Datei erleichtert die Migration, belegt aber kein identisches Verhalten jeder Action, Berechtigungsannahme und Integration.

KI-Programmierassistent: Auf den geprüften Produkt- und Preisseiten des Herstellers wird kein eigener Programmierassistent beworben. Das ist eine engere Aussage als ein KI-Verbot. Bei einem separaten Editor-Assistenten oder Review-Bot sind Repository-Zugriff, Datenverarbeitung und Integrationsunterstützung eigenständig zu prüfen.

Import aus GitHub: Die Gitea-Migrationsdokumentation beschreibt das integrierte GitHub-Migrationsformular, das bei Angabe der erforderlichen Kontodaten unter anderem Issues und Pull Requests übernimmt. Ein repräsentatives Projekt importieren und anschließend Diskussionen und Identitäten prüfen. Actions-Konfiguration und Secrets benötigen eine weitere Abnahmeprüfung.

Eine private interne Anwendung kann beispielsweise einen einfachen Testablauf besitzen, während ihr Release-Job einen bestimmten gehosteten Identitätsanbieter voraussetzt. Die Wiederverwendung des Test-Jobs validiert den Release-Job nicht. Der Pilot sollte die Deployment-Umgebung erreichen und die Wiederherstellung nachweisen, bevor die Migration als abgeschlossen gilt.

Gitea verkauft auch verwaltete Cloud- und Enterprise-Angebote und ist daher nicht ausschließlich für den Eigenbetrieb gedacht. Diese Empfehlung betrifft die selbst administrierte Open-Source-Bereitstellung. Unternehmensfunktionen wie SAML-Single-Sign-on, das die Anmeldung an das Identitätssystem der Organisation anbindet, sollten anhand der Edition geprüft werden. Ihre Verfügbarkeit in der kostenlosen Installation darf nicht vorausgesetzt werden.

Gitea vs GitLab: Welchen Betriebsumfang braucht das Team?

Gitea passt, wenn eine konzentrierte Entwicklungsplattform die Arbeit abdeckt und ihr Betrieb intern geleistet werden kann. GitLab Self-Managed passt, wenn der umfassendere GitLab-Arbeitsablauf den Wechsel begründet und der damit verbundene Verwaltungsaufwand akzeptiert wird. Bei beiden sollte der kostenlose Softwaredownload nicht das einzige Argument sein. Zu den Betriebskosten gehören die Person, die ein fehlgeschlagenes Backup untersucht, und die während eines Ausfalls verlorene Entwicklungszeit.

Codeberg ist der verwaltete Dienst; Forgejo ist die dort eingesetzte Software. Forgejo selbst zu betreiben ist eine andere Option als ein Codeberg-Konto. Auch SourceHuts Software kann auf eigener Infrastruktur installiert werden. Diese Unterscheidungen verhindern einen häufigen Auswahlfehler: Ein gehosteter Open-Source-Dienst verspricht nicht, dass sein Anbieter auch eine private Installation betreibt.

Bei Bitbuckets Eigenbetriebsangebot ist die Berechtigung gesondert zu prüfen. Atlassians Hybrid-License-Seite beschränkt das Angebot auf bestehende Bitbucket- oder Bamboo-Server/Data-Center-Kunden. Für ein Unternehmen, das von GitHub aus neu einsteigt, ist das kein Weg zum Eigenbetrieb. Ebenso darf die allgemeine Ankündigung zur Einstellung von Data Center nicht pauschal so verstanden werden, dass Bitbuckets selbst verwaltetes Produkt verschwindet.

Welche GitHub-Alternativen passen zum eigenen Team?

Ist der Preis das Hauptproblem, zählt vor dem Wechsel die gesamte Arbeitsumgebung. Für ein kleines Unternehmen bieten sich zunächst die kostenlosen Hosting-Kontingente an. Build-Kapazität, Aufgabenverwaltung, erforderliche Identitätskontrollen und Assistentenzugang gehören in die Rechnung. Der Wechsel lohnt erst, wenn Ersparnis oder Kontrollgewinn auch nach dem Nachbau des Release-Prozesses bestehen bleiben.

Ist Infrastrukturkontrolle zwingend, beginnt die Auswahl bei Gitea und GitLab Self-Managed. Für GitLab spricht, wenn die breitere Plattform genügend separate Tools ersetzt, um ihren Betriebsumfang zu rechtfertigen. Für Gitea spricht, wenn Repositorys, Issues, Reviews und eine passende CI-Lösung die Aufgabe abdecken.

Hat die Integration ins bestehende Ökosystem Vorrang, folgt die Auswahl dem Ort der Arbeitskoordination. Bitbucket passt zur Planung in Jira. Azure DevOps passt zu Boards und Pipelines. CodeCommit erfüllt einen konkreten AWS-Repository-Bedarf. Ein weiteres Ökosystem allein zur Vermeidung einer Rechnung einzuführen, kann mehr Verwaltungsaufwand schaffen als beseitigen.

Ist das Projekt öffentlich und communitygetragen, entscheidet die Eignung für Mitwirkende. Für ein freies Softwareprojekt mit Wunsch nach einer vertrauten Entwicklungsplattform ist Codeberg die klarere Wahl. SourceHut passt zu Maintainern, die den Patch-Review-Ablauf bewusst wählen und die KI-Regeln einhalten können. Bei beiden reicht „kostenlos“ in einer Überschrift als Auswahlgrund nicht aus.

Alternativen zu GitHub Actions: zuerst den Release-Job testen

GitLab CI/CD, Bitbucket Pipelines, Azure Pipelines, Gitea Actions, Codebergs CI-Angebote und SourceHut-Builds decken unterschiedliche Betriebsmodelle ab. CodeCommit wird an einen separaten AWS-Auslieferungsverbund angebunden. Migrationseinheit ist deshalb die funktionierende Pipeline und nicht ihre Konfigurationsdatei.

Alle vom aktuellen Host abhängigen Schritte erfassen: Checkout, Caches, Paketzugriff, Deployment-Zugangsdaten, Freigaben und Benachrichtigungen. Den Release-Job mit den strengsten Rahmenbedingungen früh testen. Kann er am Ziel nicht sicher laufen, hat ein erfolgreicher Repository-Import das Hindernis nicht beseitigt. Giteas Kompatibilität kann Umschreibaufwand sparen, ersetzt diesen Test aber nicht.

Alternativen zu GitHub Copilot: Assistent und Hosting getrennt bewerten

Ein geändertes Git-Remote legt weder fest, welchen Assistenten Entwickler nutzen dürfen, noch wohin dieser Kontext übermittelt. GitLab bietet Duo; Atlassian stellt seine Rovo-Entwicklertools gerade um; Microsofts Review-Integration für Azure Repos nutzt GitHub Copilot; AWS bietet Amazon Q Developer separat an. Giteas geprüfte Seiten bewerben kein integriertes Gegenstück. Codeberg und SourceHut treffen dagegen Richtlinienentscheidungen, die über die Assistentenwahl hinaus Aufmerksamkeit erfordern.

Die Anforderung muss präzise lauten: kein Training mit eingereichtem Code, keine externe Verarbeitung, keine generierten Beiträge oder keine Abhängigkeit von einem bestimmten Anbieter. Das sind unterschiedliche Richtlinien. Eine Plattform kann eine erfüllen und an einer anderen scheitern. Unser Preisleitfaden zu GitHub Copilot hilft, die Assistentenkosten getrennt vom Repository-Hosting zu bewerten.

Datenstandort: dem Code über das Repository hinaus folgen

Der Standort eines Repositorys ist nur ein Teil der Frage nach dem Datenstandort. Ein Build-Runner kann Quellcode erhalten, ein Protokoll sensible Ausgaben enthalten und ein KI-Dienst Codeausschnitte empfangen – unabhängig vom Speicherort der Git-Objekte. Für Entwicklungsverantwortliche, die eine Kundenanforderung umsetzen müssen, ist eine Übersicht dieser Übertragungen und der zugehörigen Verträge das nützliche Ergebnis.

Microsofts Dokumentation zu Azure-DevOps-Datenstandorten beschreibt wählbare geografische Regionen, darunter Europa und Kanada, sowie begrenzte Ausnahmen beim Standort von Kundendaten. Codeberg beschreibt seine Infrastrukturstandorte, ersetzt aber keinen privaten kommerziellen Hosting-Vertrag. Eigenbetrieb ermöglicht die Wahl der Bereitstellung; ein externer Assistent oder Build-Dienst wird dadurch nicht automatisch eingeschränkt.

Zu klären ist, wo Repositorys, Datenbanken, Backups und Protokolle liegen, von wo der Support darauf zugreifen kann und welche Unterauftragsverarbeiter Code erhalten. Dieselbe Prüfung ist anschließend für CI und KI nötig. Lautet die Anforderung „Kein Code verlässt diese Umgebung“, muss das an den jeweiligen Verbindungen durchgesetzt werden. Die Wahl einer Hosting-Region beantwortet die Frage nicht vollständig.

Was beim Abschied von GitHub verloren geht

Ein Teil von GitHubs Netzwerkeffekt entfällt: Potenzielle Mitwirkende haben dort bereits Konten, kennen die Review-Oberfläche und können Projekte über vertraute Profile und Repositorys entdecken. Ebenso entfällt die Annahme, dass eine Komponente aus dem Actions-Marktplatz am Ziel unverändert mit denselben Berechtigungen und Integrationen funktioniert. Die Auffindbarkeit eines Open-Source-Projekts wird stärker zur eigenen Aufgabe, selbst wenn die Alternative eine kompetente Community besitzt. Für ein öffentliches Entwicklertool, das Mitwirkende gewinnen möchte, wiegen diese Kosten schwerer als für eine private interne Anwendung. Ein öffentlicher Spiegel kann Sichtbarkeit erhalten, braucht aber eindeutige Beitragsregeln und einen klar benannten maßgeblichen Projektstandort. Sonst entstehen doppelte Issues und Reviews, die Maintainer überwachen müssen.

Wie die Auswahl zustande kam

Die Auswahl stellt belastbare Entscheidungsgrundlagen über Ranglisten nach Funktionsanzahl. Jede Option wurde auf aktuelle Verfügbarkeit, Hosting-Modell, CI/CD, Issues und Reviews, das erklärte KI-Angebot, den GitHub-Importweg und den veröffentlichten Einstiegspreis geprüft. GitLab, Bitbucket, Azure DevOps und Gitea boten Registrierungs-, Kauf-, Test- oder Downloadwege; Codeberg und SourceHut boten Registrierungen; AWS bestätigte ausdrücklich die Wiederöffnung für Neukunden.

Der Vergleich wurde am 5. November 2026 anhand primärer Produkt-, Preis- und Dokumentationsseiten überprüft. Es gab weder Leistungsmessungen noch Tests der Support-Reaktionszeit oder Probemigrationen. Die Empfehlungen beurteilen auf dieser Grundlage die Eignung für bestimmte Arbeitsabläufe. Eine positive Beschreibung setzt weder die Zulässigkeitsregeln eines Projekts außer Kraft noch die Notwendigkeit, den tatsächlichen Release-Prozess zu testen.

Wann eine Alternative ausscheidet

Codeberg scheidet für ein Unternehmen mit einem privaten proprietären Produkt aus. Sein Auftrag spricht bei freier Software für den Dienst und bei gewöhnlichem privatem kommerziellem Hosting gegen ihn. Freiwillige Spenden kaufen keine anderen Nutzungsregeln.

Gehostetes SourceHut scheidet aus, wenn der übliche Beitragsprozess auf generiertem Code beruht oder das Produkt generative KI ermöglicht. Die aktuelle Richtlinie ist eine grundlegende Kompatibilitätsfrage, keine optionale Assistenteneinstellung. Ebenso ungeeignet ist der Dienst, wenn Mitwirkende einen GitHub-ähnlichen Review-Ablauf benötigen und niemand Aufwand für die Einarbeitung eingeplant hat.

Bitbucket Hybrid darf nicht als neuer Kaufweg zum Eigenbetrieb behandelt werden. Die Seite zu den Voraussetzungen nennt ausdrücklich Bestandskunden. Zu prüfen ist das hier aufgeführte Cloud-Angebot oder selbst bereitstellbare Software.

CodeCommit ist kein pauschaler Komplett-Ersatz. Es kann der richtige AWS-Repository-Dienst sein. Der umgebende Ablauf für Aufgaben und Auslieferung muss trotzdem konzipiert werden. Der frühere Registrierungsstopp ist inzwischen kein gültiger Ablehnungsgrund mehr.

Eine Migration, deren einziger Nachweis ein erfolgreicher Klon ist, ist nicht abnahmefähig. Können Reviewer die Entscheidungen hinter dem Code nicht finden oder kann das Ziel ihn nicht ausliefern, ist der Plattformwechsel unvollständig.

Checkliste für die Abnahme der Migration

Eine Migration sollte schichtweise abgenommen werden, damit eine saubere Repository-Übertragung keinen defekten Arbeitsablauf verdeckt. Die folgende Checkliste ist ein Bewertungsrahmen. Sie behauptet nicht, dass jeder Importer jede Schicht überträgt.

1. 1

   Vollständigkeit des Repositorys nachweisen

   Erwartete Branches und Tags vergleichen, repräsentative Commits prüfen und den Abruf großer Dateien bestätigen. Ein unabhängiges Backup behalten und die Quelle bis zur Abnahme der Migration erhalten.

2. 2

   Lesbarkeit der Entscheidungen nachweisen

   Ein Issue, ein abgeschlossenes Review, einen Anhang und einen Release-Hinweis prüfen. Festlegen, welche fehlende Historie importiert, archiviert oder verlinkt wird. Jemandem die Verantwortung für fehlerhafte Verweise übertragen.

3. 3

   Auslieferungsfähigkeit des Ziels nachweisen

   Zugangsdaten, Artefaktzugriff und Deployment-Freigaben gezielt einrichten. Den Release-Prozess gegen ein sicheres Ziel ausführen und anschließend die Wiederherstellung proben. Temporäre Importzugangsdaten nach der Abnahme widerrufen.

4. 4

   Zugriffe und Verantwortung für die Umschaltung nachweisen

   Die Zugriffe einer Entwicklerperson, einer Review-Person, einer Build-Identität und eines ausscheidenden Nutzers prüfen. Die abschließende Synchronisierung planen, den Ort für neue Beiträge bekannt geben und die zum Rückgängigmachen des Umzugs berechtigte Person benennen.

Die nächste Arbeitssitzung sollte ein Pilotergebnis liefern, keine längere Auswahlliste: Das Ziel wählen, das die zwingende Anforderung erfüllt, ein repräsentatives Repository migrieren und den Arbeitsablauf durch die Release-Verantwortlichen abnehmen lassen. Erst auf dieser Grundlage ausweiten.

Häufige Fragen

Was ist die beste Alternative zu GitHub?

GitLab ist der stärkste umfassende Ersatz, wenn Repositorys, Issues, Reviews und CI/CD zusammenbleiben sollen. Gitea ist die erste Option für den Eigenbetrieb, wenn eine konzentrierte Entwicklungsplattform genügt und ihr Betrieb intern möglich ist. Jira-Abhängigkeit, Community-Regeln oder eine AWS-Grenze können die Empfehlung verändern.

Was ist besser: TFS oder Git?

Das sind unterschiedliche Werkzeugarten. Team Foundation Server, der Vorgänger von Azure DevOps Server, ist eine Entwicklungsplattform. Git ist ein verteiltes Versionsverwaltungssystem. Falls Git mit Team Foundation Version Control verglichen werden soll, erklärt Microsofts TFVC-Übersicht die zentralisierte Alternative. Für einen anderen Repository-Host muss Git nicht aufgegeben werden.

Nutzt die NASA Git?

Ja. Die NASA beschreibt in ihrer Übersicht zur Open-Source-Entwicklung, dass sie GitHub zur Veröffentlichung von Open-Source-Software nutzt. Das belegt den tatsächlichen Einsatz von Git-Repositorys, keine allgemeine Regel für jedes NASA-System.

Ist GitHub noch Open Source?

GitHubs gehostete Plattform ist proprietär. Git, das zugrunde liegende Versionsverwaltungswerkzeug, ist Open Source, und GitHub hostet viele Open-Source-Projekte. Das sind unterschiedliche Dinge: Die Wahl eines Open-Source-Projekts bedeutet nicht die Wahl einer offenen Hosting-Plattform.

Warum boykottieren Menschen GitHub?

Die Gründe unterscheiden sich. Dazu gehören Einwände gegen proprietäres Hosting, Anbieterabhängigkeit und KI-Nutzung. Codeberg und SourceHut veröffentlichen ausdrückliche Positionen zu KI und Software-Governance, wie oben beschrieben. Für die eigene Organisation sollte aus dem Einwand eine überprüfbare Anforderung werden, statt bei jeder Alternative dieselben Regeln vorauszusetzen.

Was ist GitHub, einfach erklärt?

GitHub ist ein gemeinsamer Arbeitsbereich für Code. Es speichert die Änderungshistorie, ermöglicht Änderungsvorschläge und Reviews und unterstützt Aufgabenverwaltung und Automatisierung. Die Alternativen unterscheiden sich darin, wie viel dieses Arbeitsbereichs sie bereitstellen und wer ihn betreibt.

Wie riskant ist GitHub?

Die nützliche Frage lautet, welches Risiko beherrscht werden muss: Kontozugriffe, offengelegte Zugangsdaten, Repository-Berechtigungen, Automatisierung durch Dritte oder Datenübertragungen. Ein Anbieterwechsel beseitigt diese Aufgaben nicht. Beim Eigenbetrieb kommen Patches, Backups und Wiederherstellung zur eigenen Verantwortung hinzu.

Gehört GitHub zu 100% Microsoft?

Ja. Microsoft schloss die Übernahme von GitHub 2018 ab, wie die Übernahmemitteilung dokumentiert. Ein Wechsel zu Azure DevOps ändert die Plattform, während Microsoft der Anbieter bleibt.

Nutzt die US-Regierung GitHub?

Ja. Der veröffentlichte Einsatz durch die NASA ist ein dokumentiertes Beispiel einer US-Bundesbehörde. Daraus folgt keine Freigabe von GitHub oder einer Alternative für jedes Behördenprojekt oder jede Informationskategorie.

Vor dem Umbau der Entwicklungsumgebung hilft die Checkliste für das KI-Geschäftsprozess-Audit, festzuhalten, was der neue Arbeitsablauf erhalten muss.