Hurtige checkouts med fuld historik

actions/checkout henter som standard ét commit (fetch-depth: 1). Det er det hurtigste checkout og det rigtige til de fleste jobs.

Nogle jobs har brug for historik: at sammenligne en pull request med dens basebranch, at finde det seneste release-tag eller at generere en changelog. De sætter fetch-depth: 0, som henter alle versioner af alle filer, repoet nogensinde har haft. De fleste af disse jobs læser kun commits og filnavne, aldrig det gamle filindhold.

Tilføj én linje

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

filter: blob:none laver en partial clone: alle commits og mappelister, men kun filindhold for det commit, du tjekker ud. Hvis et senere step læser en ældre version af en fil, henter git den i det øjeblik.

Hvad det sparer

Målt på et repository med ca. 5.000 filer og 4.600 commits, på hostede runners i oktober 2026:

Besparelsen vokser med repoets historik. Et ungt repository med få commits vinder kun lidt.

Hvornår du skal bruge det

Brug det, når jobbets git-kommandoer læser commits, branches, tags eller navne på ændrede filer, for eksempel:

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

Lad være, når jobbet læser gammelt filindhold på tværs af mange commits, for eksempel git log -p over et langt interval, git blame på mange filer eller et værktøj, der gennemgår alle historiske versioner. Hver manglende fil hentes så efter behov, hvilket kan være langsommere end den fulde clone.

En git diff, der viser indhold (ikke kun navne) mellem to commits, henter kun de filer, der er ændret, i én samlet omgang. Det er som regel stadig hurtigere end en fuld clone.

Hvorfor det ikke er standard

fremforge slår det ikke til for alle jobs, af to grunde:

• Det gør standard-checkout langsommere. Med fetch-depth: 1 kræver en partial clone en ekstra rundtur for filerne, så den bliver langsommere, ikke hurtigere.
• Repoet skal have sine egne indstillinger, for at det virker. Inputtet filter skriver partial clone-indstillingerne ind i det udtjekkede repository, så ethvert senere step kan hente det, det mangler. En indstilling, der gælder for runneren som helhed, ville ikke følge med repoet, og et step, der kører med en anden hjemmemappe, for eksempel i en job-container, ville fejle ved den første manglende fil.

Valget er derfor dit, workflow for workflow.