Herunterladen von Quellcodearchiven

Übersicht über Quellcodearchive

Sie können eine Momentaufnahme eines beliebigen Branchs, Tags oder bestimmter Commits aus GitHub herunterladen. Diese Momentaufnahmen werden vom git archive-Befehl in einem von zwei Formaten generiert: Tarball oder Zipball. Momentaufnahmen enthalten nicht den gesamten Repositoryverlauf. Wenn du den gesamten Verlauf möchtest, kannst du das Repository klonen. Weitere Informationen finden Sie unter Ein Repository klonen.

Herunterladen von Quellcodearchiven

Du kannst die Quellcodearchive auf drei Arten herunterladen.

Herunterladen von Quellcodearchiven aus der Repositoryansicht

1. Navigieren Sie auf GitHub zur Hauptseite des Repositorys.

2. Klicke oberhalb der Liste der Dateien auf Code.

   

3. Klicke auf ZIP herunterladen.

Herunterladen von Quellcodearchiven aus einem Release

1. Navigieren Sie auf GitHub zur Hauptseite des Repositorys.

2. Klicke rechts neben der Liste der Dateien auf Releases.

   

3. Scrolle zum Abschnitt „Ressourcen“ des Release.

4. Um den Quellcode herunterzuladen, klicke auf Quellcode (.zip) oder Quellcode (tar.gz) .

Herunterladen von Quellcodearchiven aus einem Tag

1. Navigieren Sie auf GitHub zur Hauptseite des Repositorys.

2. Klicke rechts neben der Liste der Dateien auf Releases.

   

3. Klicke oben auf der Seite „Releases“ auf Tags.

4. Um den Quellcode herunterzuladen, klicke auf zip oder tar.gz.

   

Quellcodearchiv-URLs

Quellcodearchive sind unter bestimmten URLs für jedes Repository verfügbar. Betrachte beispielsweise das Repository github/codeql. Es gibt verschiedene URLs zum Herunterladen eines Branchs, eines Tags oder einer bestimmten Commit-ID.

Archivtyp	Beispiel	URL
Verzweigung	main	https://github.com/github/codeql/archive/refs/heads/main.tar.gz
Tag	codeql-cli/v2.12.0	https://github.com/github/codeql/archive/refs/tags/codeql-cli/v2.12.0.zip
Commit	aef66c4	https://github.com/github/codeql/archive/aef66c462abe817e33aad91d97aa782a1e2ad2c7.zip

Stabilität von Quellcodearchiven

Quellcodearchive werden auf Anforderung generiert, eine Weile zwischengespeichert und dann gelöscht. Wenn dasselbe Archiv in Zukunft erneut angefordert wird, wird es neu generiert. Es ist wichtig zu verstehen, was GitHub für Quellcodearchive garantiert.

• Das Archiv einer Commit-ID hat immer dieselben Dateiinhalte, egal, wann es angefordert wird. Dabei wird davon ausgegangen, dass die Commit-ID immer noch das Repository ist und der Name des Repositorys nicht geändert wurde.
• Da Branches und Tags in unterschiedliche Commit-IDs verschoben werden können, können zukünftige Downloads eines Archivs einen anderen Inhalt aufweisen als zuvor heruntergeladene Archive desselben Branchs oder Tags. Wenn Branches oder Tags weiterhin auf dieselbe Commit-ID verweisen, weisen sie denselben Dateiinhalt auf.
• Die genauen Komprimierungseinstellungen, die zur Zipball- oder Tarball-Generierung verwendet werden, können sich im Laufe der Zeit ändern. Der extrahierte Inhalt ändert sich nicht, wenn sich der Branch oder das Tag nicht ändert, aber das äußere komprimierte Archiv kann ein anderes Bytelayout aufweisen. GitHub sendet mindestens sechs Monate vor dem Ändern der Komprimierungseinstellungen eine Benachrichtigung.
• Der Name des Repositorys ist Teil der Verzeichnisstruktur im Archiv. Wenn sich der Repositoryname ändert, ändert sich daher auch der Name des Stammverzeichnisses.

Wenn du dich auf die Stabilität von Quellcodearchiven für die Reproduzierbarkeit verlässt (um sicherzustellen, dass du immer identische Dateien innerhalb des Archivs erhältst), empfehlen wir die Verwendung der REST-API für Archive mit einer Commit-ID für :ref. Die Verwendung der Commit-ID stellt sicher, dass du immer denselben Dateiinhalt innerhalb des Archivs erhältst, und du bist immun gegen das Umschreiben von Tags oder das Verschieben von Branchköpfen von Repositorys.

Wenn du dich aus Sicherheitsgründen auf die Stabilität von Archiven verlässt (z. B. um sicherzustellen, dass du nicht versuchst, eine böswillig erstellte Datei zu entzippen), empfehlen wir die Verwendung von Releases anstelle von Quelldownloads. Weitere Informationen finden Sie unter Informationen zu Releases.

Du kannst etwa diese GitHub-Aktion eines Drittanbieters verwenden, um diese Dateien im Rahmen deines Freigabeprozesses zu erstellen und zu pushen. Die REST-API für Releaseressourcen kann später verwendet werden, um sie abzurufen.