Schnelle Checkouts mit vollständiger Historie

actions/checkout holt standardmäßig einen einzigen Commit (fetch-depth: 1). Das ist der schnellste Checkout und für die meisten Jobs der richtige.

Manche Jobs brauchen Historie: um einen Pull-Request mit seinem Basis-Branch zu vergleichen, das letzte Release-Tag zu finden oder ein Changelog zu erzeugen. Sie setzen fetch-depth: 0 und laden damit jede Version jeder Datei, die das Repository je hatte. Die meisten dieser Jobs lesen aber nur Commits und Dateinamen, nie die alten Dateiinhalte.

Eine Zeile ergänzen

- uses: actions/checkout@v4
  with:
    fetch-depth: 0
    filter: blob:none

filter: blob:none erzeugt einen partiellen Klon: alle Commits und Verzeichnislisten, Dateiinhalte aber nur für den Commit, den du auscheckst. Liest ein späterer Schritt eine ältere Version einer Datei, lädt git sie in diesem Moment nach.

Was es spart

Gemessen an einem Repository mit etwa 5.000 Dateien und 4.600 Commits, auf gehosteten Runnern, Oktober 2026:

Die Ersparnis wächst mit der Historie des Repositorys. Ein junges Repository mit wenigen Commits gewinnt wenig.

Wann du es einsetzt

Setze es ein, wenn die git-Befehle des Jobs Commits, Branches, Tags oder die Namen geänderter Dateien lesen, zum Beispiel:

• git diff --name-only origin/main...HEAD
• git log --oneline, git describe --tags
• git merge-base

Lass es weg, wenn der Job alte Dateiinhalte über viele Commits hinweg liest, zum Beispiel git log -p über einen langen Bereich, git blame auf vielen Dateien oder ein Werkzeug, das jede historische Version durchläuft. Jede fehlende Datei wird dann einzeln nachgeladen, was langsamer sein kann als der vollständige Klon.

Ein git diff, der Inhalte (nicht nur Namen) zwischen zwei Commits zeigt, lädt nur die geänderten Dateien, und zwar in einem Durchgang. Das ist meist trotzdem schneller als ein vollständiger Klon.

Warum das nicht der Standard ist

fremforge schaltet das nicht für jeden Job ein, aus zwei Gründen:

• Es verlangsamt den Standard-Checkout. Mit fetch-depth: 1 braucht ein partieller Klon einen zweiten Roundtrip für die Dateien und ist damit langsamer, nicht schneller.
• Das Repository braucht eigene Einstellungen, damit es funktioniert. Der Eingabewert filter schreibt die Einstellungen für den partiellen Klon in das ausgecheckte Repository, sodass jeder spätere Schritt nachladen kann, was er braucht. Eine Einstellung für den ganzen Runner würde nicht mit dem Repository mitwandern, und ein Schritt mit einem anderen Home-Verzeichnis, etwa in einem Job-Container, würde an der ersten fehlenden Datei scheitern.

Die Entscheidung bleibt also bei dir, pro Workflow.