Hoppa till huvudinnehållet

Snabba utcheckningar med full historik

actions/checkout hämtar som standard en enda commit (fetch-depth: 1). Det är den snabbaste utcheckningen och den rätta för de flesta jobb.

Vissa jobb behöver historik: att jämföra en pull request med dess bas-branch, hitta den senaste release-taggen eller generera en ändringslogg. De sätter fetch-depth: 0, som laddar ner varje version av varje fil som repot någonsin har haft. De flesta av de jobben läser bara commits och filnamn, aldrig det gamla filinnehållet.

Lägg till en rad

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

filter: blob:none ger en partiell klon: alla commits och kataloglistningar, men filinnehåll bara för den commit du checkar ut. Om ett senare steg läser en äldre version av en fil laddar git ner den i just det ögonblicket.

Vad det sparar

Uppmätt i ett repo med cirka 5 000 filer och 4 600 commits, på hostade runners i oktober 2026:

UtcheckningHämtningUtcheckning av filerTotalt
fetch-depth: 023,4 s0,5 scirka 24 s
fetch-depth: 0 + filter: blob:none3,4 till 3,9 s6,4 till 6,5 scirka 10 s

Besparingen växer med repots historik. Ett ungt repo med få commits vinner lite.

När du ska använda det

Använd det när jobbets git-kommandon läser commits, branches, taggar eller namn på ändrade filer, till exempel:

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

Låt bli när jobbet läser gammalt filinnehåll över många commits, till exempel git log -p över ett långt intervall, git blame på många filer eller ett verktyg som går igenom varje historisk version. Varje fil som saknas laddas då ner vid behov, vilket kan bli långsammare än en full klon.

En git diff som visar innehåll (inte bara namn) mellan två commits laddar bara ner de filer som ändrats, i en enda omgång. Det är oftast ändå snabbare än en full klon.

Varför det inte är standard

fremforge slår inte på detta för alla jobb, av två skäl:

  • Det gör standardutcheckningen långsammare. Med fetch-depth: 1 behöver en partiell klon en andra rundtur för filerna, så den blir långsammare, inte snabbare.
  • Repot behöver sina egna inställningar för att det ska fungera. Indata filter skriver inställningarna för partiell klon i det utcheckade repot, så att varje senare steg kan hämta det det behöver. En inställning som gäller hela runnern följer inte med repot, och ett steg som körs med en annan hemkatalog, till exempel i en jobbcontainer, skulle misslyckas vid första fil som saknas.

Valet ligger alltså hos dig, per arbetsflöde.