Raske checkouts med full historikk

actions/checkout henter som standard én commit (fetch-depth: 1). Det er den raskeste checkouten, og den riktige for de fleste jobber.

Noen jobber trenger historikk: å sammenligne en pull request med base-branchen, å finne siste release-tag eller å generere en endringslogg. Disse setter fetch-depth: 0, som laster ned alle versjoner av alle filer repositoryet noen gang har hatt. De fleste av disse jobbene leser bare commits og filnavn, aldri det gamle filinnholdet.

Legg til én linje

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

filter: blob:none lager en delvis klon: alle commits og katalogoppføringer, og filinnhold bare for commiten du sjekker ut. Hvis et senere steg leser en eldre versjon av en fil, laster git den ned i det øyeblikket.

Hva det sparer

Målt på et repository med rundt 5 000 filer og 4 600 commits, på hostede runnere, oktober 2026:

Besparelsen vokser med historikken til repositoryet. Et ungt repository med få commits vinner lite.

Når du bør bruke det

Bruk det når git-kommandoene i jobben leser commits, brancher, tagger eller navn på endrede filer, for eksempel:

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

La det være av når jobben leser gammelt filinnhold på tvers av mange commits, for eksempel git log -p over et langt intervall, git blame på mange filer eller et verktøy som går gjennom alle historiske versjoner. Hver fil som mangler, lastes da ned ved behov, noe som kan gå tregere enn en full klon.

En git diff som viser innhold (ikke bare navn) mellom to commits, laster ned bare filene som er endret, i én omgang. Det er som regel fortsatt raskere enn en full klon.

Hvorfor dette ikke er standard

fremforge slår ikke dette på for alle jobber, av to grunner:

• Det gjør standard-checkouten tregere. Med fetch-depth: 1 trenger en delvis klon en ekstra rundtur for filene, så den blir tregere, ikke raskere.
• Repositoryet trenger sine egne innstillinger for at det skal virke. Inputen filter skriver innstillingene for delvis klon inn i det utsjekkede repositoryet, slik at et hvilket som helst senere steg kan hente det det trenger. En innstilling som gjelder hele runneren, ville ikke fulgt med repositoryet, og et steg som kjører med en annen hjemmekatalog, for eksempel inne i en jobbcontainer, ville feilet på den første filen som mangler.

Derfor er valget ditt, per workflow.