Blog

Migration von Bitbucket-Repositorys und -Pipelines zu GitHub Actions

14.04.2026
Lesezeit: 3 Minuten.
Letzte Aktualisierung: 23 .04.2026

Inhaltsübersicht

Die Migration von CI/CD-Pipelines ist eine häufige Aufgabe für DevOps-Ingenieure, insbesondere da Teams zunehmend auf einheitlichere und modernere Bereitstellungsplattformen umsteigen. In dieser Fallstudie aus der Praxis zeigen wir Ihnen Schritt für Schritt, wie mehrere Bitbucket-Repositorys und -Pipelines zu GitHub migriert werden, während gleichzeitig die CI-Workflows mithilfe von GitHub Actions modernisiert werden.

Die betroffenen Repositorys waren für Firmware-Builds verantwortlich, die auf OpenWRT und Yocto, zwei weit verbreitete Linux-basierte Frameworks für eingebettete Systeme. Das Ziel bestand nicht nur in der Migration des Quellcodes, sondern auch in der Konsolidierung fragmentierter Pipeline-Implementierungen zu einer einzigen, einheitlichen CI/CD-Architektur.

Dieser Artikel ist Teil 1 einer Reihe zum Thema Migration, in der es um die Migration von Repositorys und die Beibehaltung der Git-Historie, -Struktur und -Abhängigkeiten geht.

Die von dieser Migration betroffenen Repositorys verfügten über unterschiedliche CI-Implementierungen:

  • Einige nutzten Bitbucket Pipelines und setzten dabei auf YAML-definierte Workflows
  • Andere führten Bash-Skripte über Jenkins-Jobs aus

Eine der größten Herausforderungen bestand darin, diese Ansätze unter einer einzigen CI/CD-Plattform zu vereinen. Die vollständige Migration zu GitHub und die Vereinheitlichung auf GitHub Actions schufen eine übersichtliche und wartungsfreundliche Grundlage für die zukünftige Entwicklung.

Der Migrationsprozess umfasste drei Hauptziele:

  1. Repositorys von Bitbucket Cloud zu GitHub Cloud verschieben
  2. Behalte den vollständigen Git-Verlauf bei, einschließlich Zweigen, Tags und Referenzen
  3. Stellen Sie sicher, dass Submodule und Abhängigkeiten weiterhin ordnungsgemäß funktionieren

Da es sich um eine Bitbucket-Cloud-Umgebung handelte, kamen nicht alle Migrationswerkzeuge in Frage. Man entschied sich für einen direkten Git-basierten Ansatz, um während des gesamten Prozesses volle Kontrolle und Transparenz zu gewährleisten.

Für jedes Projekt wurde auf GitHub ein leeres Repository angelegt, das denselben Namen trug wie das ursprüngliche Bitbucket-Repository. Dieses Repository diente als Ziel für die Migration.

Bitbucket

Um den vollständigen Zustand des Repositorys einschließlich aller Branches und Tags zu erhalten, wurde ein gespiegelter Klon erstellt:

git clone --mirror git@bitbucket.org:workspace/project-repo.git

This creates a bare repository containing all Git objects and references, without checking out a working directory. A typical structure looks like:
branches  config  description  HEAD  hooks  info  objects  packed-refs  refs

Dies bestätigt, dass der gesamte Git-Verlauf lokal verfügbar ist.

Anschließend wurde das gespiegelte Repository auf GitHub hochgeladen:

cd project-repo.git
git push --mirror git@github.com:workspace/project-repo.git

Dadurch wird sichergestellt, dass alle Branches, Tags und Referenzen genau so übertragen werden, wie sie in Bitbucket Cloud vorhanden waren.

Nachdem das Repository gepusht worden war, wurden mehrere Überprüfungen durchgeführt:

  • Stellen Sie sicher, dass alle Zweige korrekt migriert wurden
  • Überprüfen Sie, ob die Tags und der Commit-Verlauf intakt sind
  • Stellen Sie sicher, dass der richtige Standardzweig festgelegt ist

Bei Bedarf kann der Standard-Branch in GitHub wie folgt aktualisiert werden:

Repository → Einstellungen → Allgemein → Standardzweig

Bitbucket

Diese Überprüfungen stellen sicher, dass das Repository für die Migration der CI/CD-Pipeline bereit ist.

Viele der migrierten Repositorys nutzten Git-Submodule. Nach der Migration mussten alle Submodul-URLs aktualisiert werden, damit sie nun auf GitHub statt auf Bitbucket verweisen.

Vor der Migration:

[submodule "submodule_name"]
  path = submodule_path
  url = git@bitbucket.org:workspace/dependant-repo.git

Nach der Migration:

[submodule "submodule_name"]
  path = submodule_path
  url = git@github.com:workspace/dependant-repo.git

Nach der Aktualisierung die Submodule initialisieren und aktualisieren:

git submodule update --init --recursive

In einigen Fällen enthielten die Submodule selbst verschachtelte Submodule. Diese verschachtelten Abhängigkeiten verweisen möglicherweise noch auf alte Bitbucket-URLs.

Um sicherzustellen, dass die interne Konfiguration von Git vollständig aktualisiert ist, führen Sie folgenden Befehl aus:

git submodule sync --recursive

Dieser Schritt ist besonders wichtig, wenn Sie mit bereits initialisierten Repositorys arbeiten.

Einige Submodule wurden an bestimmte Commit-SHAs gebunden, um die Stabilität des Builds zu gewährleisten. Die Beibehaltung dieser Verweise ist für Firmware-Builds und reproduzierbare Pipelines von entscheidender Bedeutung.

Schritte zum Speichern eines bestimmten Commits:

cd submodule_path
git checkout <commit-sha>

Kehren Sie dann zum Haupt-Repository zurück:

git add submodule_path
git commit -m "Preserve submodule at specific commit SHA"
git push origin <branch-name>

Dadurch wird sichergestellt, dass das Repository weiterhin genau die Submodul-Version verwendet, die für den Build-Prozess erforderlich ist.

Damit ist Teil 1 unserer Serie über die Migrationsreise abgeschlossen.

Im nächsten Beitrag konzentrieren wir uns darauf, Projektabhängigkeiten sicher zu aktualisieren und sicherzustellen, dass die Builds und Pipelines, die wir migrieren wollen, weiterhin reibungslos funktionieren. Seid gespannt auf Teil 2!


Weitere Blogbeiträge findest du hier.

Mehr Beiträge

Die ITGix AWS Landing Zone wird kontinuierlich weiterentwickelt, wobei ein klares Ziel im Vordergrund steht: Unternehmen sollen in die Lage versetzt werden, sichere, konforme und skalierbare AWS-Umgebungen mit geringerem Betriebsaufwand aufzubauen. In den jüngsten Versionen (v1.2.0...
Lesen
In früheren Artikeln haben wir uns mit der Migration von Repositorys aus der Bitbucket Cloud, der sicheren Aktualisierung von Projektabhängigkeiten und der Modernisierung von CI/CD-Workflows durch die Umstellung von Jenkins- und Bash-basierten Pipelines auf GitHub Actions befasst. Auf dieser Grundlage...
Lesen
Kontakt aufnehmen
ITGix bietet Ihnen fachkundige Beratung und maßgeschneiderte DevOps-Services, um Ihr Unternehmenswachstum zu beschleunigen.
Newsletter für
Technik-Experten
Schließen Sie sich 12.000+ Geschäftsführern und Ingenieuren an, die Blogs, e-Books und Fallstudien Fallstudien über neue Technologie erhalten.