GitHub Stacked PRs: Opdel AI-Kode I 12 Trin [2026]

GitHub gjorde i oktober 2026 stacked pull requests generelt tilgængelige for alle repositories, samtidig med at Copilot fik lokal sandboxing og en ny model til at opdage lækkede secrets. De tre funktioner hænger sammen på en måde, de færreste teams har fået sat op endnu: når en AI-agent skriver 400 linjer kode i én omgang, er svaret ikke en kæmpe pull request, der tager en hel formiddag at gennemgå. Svaret er at splitte ændringen i en kæde af små, afhængige pull requests, som hver kan godkendes for sig. Denne guide viser, hvordan du bygger det workflow fra bunden med GitHub CLI, GitHub Copilot og VS Code, i 12 konkrete trin.

Guiden er skrevet til udviklere, der allerede bruger GitHub Copilot eller en anden AI-agent til at generere kode, og som har oplevet, at den største flaskehals ikke længere er at få koden skrevet, men at få den gennemgået og merget forsvarligt. Du skal ikke være Git-ekspert for at følge med, men du skal kunne navigere grundlæggende branch-kommandoer. Vi bygger et komplet, kørende eksempelprojekt undervejs, så du har noget konkret at teste på, i stedet for blot at læse teori om, hvordan stakning fungerer i abstrakte vendinger.

Ifølge Stack Overflows udviklerundersøgelse fra oktober 2026 bruger 73 procent af dem, der bruger AI-kodeassistenter, dem dagligt, og næsten en tredjedel af de daglige brugere sidder med AI-værktøjer fire timer eller mere om dagen (Stack Overflow). Det er ikke generering af kode, der er flaskehalsen længere. Det er at validere den. Digital Applied fandt i sin egen udviklerundersøgelse for 2026, at teams nu bruger 11,4 timer om ugen på at gennemgå AI-genereret kode, mere tid end de bruger på selv at skrive den. Stacked pull requests løser et konkret problem i den ligning: de gør store ændringer gennemgåelige, uden at du skal vente på, at hele funktionen er færdig, før den første del kan merges.

Hvorfor stacked pull requests er blevet uundgåelige i 2026

Når en AI-agent arbejder uafbrudt i en terminal eller i VS Code, producerer den typisk ændringer, der rammer flere filer og lag samtidig: database-skema, API-endpoint og frontend i samme hug. Det er praktisk, når koden skal skrives, men det er et problem, når koden skal godkendes. En reviewer kan ikke vurdere skema-ændringer, forretningslogik og UI i én samlet diff uden at miste overblikket, og fejl gemmer sig netop i de store, blandede commits.

GitHubs eget changelog for oktober 2026 bekræfter, at stacked pull requests nåede generel tilgængelighed i samme udgivelsescyklus som lokal sandboxing i Copilot CLI, Copilot-appen og VS Code Agent Host, samt en nyudviklet model, der er bygget specifikt til at finde lækkede secrets i kode (GitHub Changelog). Det er ikke en tilfældighed, at de tre ting kom samtidig. GitHub bygger tydeligvis mod et samlet workflow: generér i agent, isolér eksekveringen i en sandbox, opdel ændringen i en stak, og lad automatiske kontroller fange secrets og fejl, før et menneske skal bruge tid på gennemgangen.

Tallene fra undersøgelsen hos Stack Overflow viser samme billede fra en anden vinkel. 67 procent af respondenterne bruger AI til at generere kode i områder, de allerede kender godt, mens 61 procent bruger AI til debugging og refaktorering. Kun 20 procent lader AI arbejde direkte med drift og produktionsfejl. Det betyder, at langt de fleste AI-genererede ændringer netop er den slags funktionsarbejde, der passer perfekt til at blive stakket: afgrænset, testbart og opdelt i logiske lag.

Der er også en menneskelig side af sagen, som rækker ud over selve kodekvaliteten. Når en reviewer skal godkende en kæmpe, blandet diff, falder tendensen til bare at trykke “approve” uden at læse grundigt, netop fordi opgaven føles uoverskuelig. Mindre, afgrænsede pull requests gør det lettere rent psykologisk at bruge de nødvendige minutter på hver ændring, i stedet for at skimme hele funktionen på fem minutter og håbe, testene fanger resten. Det er den samme logik, der ligger bag GitHub Copilots nye effort-niveauer i code review, hvor tidskrævende, dybdegående gennemgang reserveres til den kode, der faktisk kræver det.

Det er heller ikke kun GitHub Copilot, der er i spil hos de teams, dette workflow er bygget til. Ifølge Stack Overflows oktober-undersøgelse bruger 66 procent af dem, der benytter en coding-agent, Claude Code, mod 59 procent for GitHub Copilot, og mange udviklere skifter mellem flere agenter afhængigt af opgaven. Det er netop derfor, selve stak-strukturen i denne guide er bygget på almindelig Git og GitHub CLI frem for et agent-specifikt værktøj: det virker uanset hvilken AI-agent, der sad i førersædet, da den enkelte gren blev skrevet.

Hvad er stacked pull requests – kort forklaret

En stacked pull request er ikke andet end en gren, der er bygget oven på en anden gren, som endnu ikke er merget til main. I stedet for at oprette én gren med alle ændringer og én pull request mod main, opretter du en kæde: gren A mod main, gren B mod gren A, gren C mod gren B. Hver gren bliver sin egen pull request med sin egen, lille diff. Reviewerne kan godkende og merge A, hvorefter B automatisk peger mod main, og processen fortsætter.

Det lyder som noget, erfarne Git-brugere altid har kunnet gøre manuelt med rebase og flere grene, og det har de. Det nye i 2026 er, at GitHub nu holder styr på basen for dig, opdaterer target-grenen automatisk, når en forgænger merges, og viser hele stakken visuelt i pull request-oversigten, så du ikke behøver huske rækkefølgen i hovedet eller i et regneark.

Egenskab	Traditionel stor PR	Stacked pull requests
Diff-størrelse pr. review	Alt på én gang, ofte 300+ linjer	Opdelt i 50-150 linjer pr. PR
Tid til første godkendelse	Afhænger af hele funktionen	Den første gren kan godkendes med det samme
Rebase ved ændringer	Manuel, hele tiden på nye commits	Automatisk opdatering af base ved merge
Synlighed af afhængigheder	Skal forklares i PR-beskrivelsen	Vist direkte i GitHubs stak-oversigt
Egnet til AI-genereret kode	Svært at verificere i ét hug	Matcher agentens naturlige lag-opdeling

Forudsætninger: værktøjer og versioner du skal have klar

Du behøver ikke et stort team eller en kompliceret opsætning for at følge denne guide. Du skal bruge følgende, og vi bruger den nyeste stabile version af hvert værktøj, da GitHub løbende opdaterer dem:

Git, nyeste stabile version (anbefalet 2.45 eller nyere, for ordentlig --update-refs-støtte under rebase)
GitHub CLI (gh), seneste version installeret fra GitHubs officielle kanal, med gh auth login gennemført mod din konto
GitHub Copilot-abonnement med adgang til Copilot CLI og Copilot code review (Pro, Business eller Enterprise)
Visual Studio Code version 1.140 eller nyere, da september-udgivelserne af VS Code lagde fundamentet for agent-drevet udvikling fra implementering til merge
Node.js 20 LTS eller nyere, hvis du følger eksempelprojektet direkte
Et GitHub-repository, hvor du har administrator- eller skriveadgang, så du kan aktivere secret-scanning og branch protection

Du behøver ikke en kæmpe produktionskodebase for at øve dig. Vi bygger gennem guiden et lille eksempelprojekt: en Node.js-API med tre lag, en database-model, et endpoint og en valideringsmiddleware, som er stort nok til at vise, hvorfor stakning giver mening, men småt nok til at du kan følge hele forløbet på under en time.

Hvis dit team allerede arbejder i et større, eksisterende repository, kan du stadig følge trinene nedenfor direkte. Erstat blot eksempelfilerne med de faktiske filer, din feature rører, og behold princippet: hvert lag af ændringen bliver sin egen gren og sin egen pull request. Selve mekanikken i Git og GitHub CLI er identisk, uanset om det er et nyt legacy-projekt eller en kodebase med flere års historik.

Trin 1: Opret testprojektet og aktivér Copilot i repositoriet

Start med et nyt, tomt repository på GitHub, og klon det lokalt. Initialisér derefter et minimalt Node.js-projekt, som vi bygger videre på i resten af guiden.

mkdir stacked-pr-demo && cd stacked-pr-demo
git init
npm init -y
npm install express
mkdir -p src/models src/routes src/middleware
git add .
git commit -m "init: tomt Node.js-projekt"
git remote add origin [email protected]:dit-brugernavn/stacked-pr-demo.git
git push -u origin main

Gå herefter ind i repositoriets indstillinger på GitHub, og slå Copilot code review til under Settings → Copilot → Code review. Aktivér samtidig secret-scanning under Settings → Code security, så den nye model til at opdage lækkede secrets, som GitHub rullede ud i oktober 2026, dækker alle grene fra starten.

Trin 2: Installer og konfigurer GitHub CLI til stakning

GitHub CLI håndterer selve oprettelsen af stakkede pull requests. Bekræft installationen, og sæt standardrepositoriet, så du ikke skal angive det hver gang:

gh --version
gh auth status
gh repo set-default dit-brugernavn/stacked-pr-demo

Du behøver ikke en separat extension til selve stakningen. GitHub CLI’s pr create-kommando understøtter allerede at angive en vilkårlig gren som --base, hvilket er alt, stakning kræver teknisk set. Det, der gør arbejdet lettere i praksis, er disciplin omkring navngivning af grene, hvilket vi sætter op i næste trin.

Trin 3: Lad en AI-agent planlægge opdelingen, før den skriver kode

Den mest almindelige fejl, teams begår, er at lade agenten skrive hele funktionen først og derefter forsøge at skære den op bagefter. Det er langt nemmere at bede agenten planlægge lagene, før den rører en fil. Åbn Copilot Chat i VS Code, og brug en instruktion i stil med denne:

Jeg skal bygge et bruger-endpoint med validering i dette Node.js-projekt.
Opdel opgaven i tre uafhaengige, sekventielle lag:
1. Datamodel (src/models/user.js)
2. API-endpoint der bruger modellen (src/routes/users.js)
3. Valideringsmiddleware der beskytter endpointet (src/middleware/validateUser.js)
Beskriv hvert lag separat. Skriv IKKE kode for alle tre endnu,
kun en kort plan for hvert lag og hvilke filer det roerer.

Når agenten har leveret planen, har du de naturlige brudpunkter til stakken. Hvert lag bliver sin egen gren og sin egen pull request. Det er denne opdeling, der gør stacked pull requests brugbare i praksis, fordi den matcher den måde, AI-agenter allerede tænker i lag, når man beder dem om det.

Trin 4: Opret den første gren i stakken

Opret den første gren direkte fra main. Brug et navngivningsmønster, der gør rækkefølgen tydelig for hele teamet, for eksempel med et talpræfiks:

git checkout main
git pull origin main
git checkout -b stack/01-user-model
# Bed Copilot generere src/models/user.js baseret paa planen fra trin 3
git add src/models/user.js
git commit -m "feat: tilfoej User-model med felter og typer"
git push -u origin stack/01-user-model

Trin 5: Åbn den første pull request og hold den lille

Opret pull requesten mod main med GitHub CLI. Beskriv i teksten, at der kommer mere oven på denne gren, så reviewere forstår konteksten:

gh pr create \
  --base main \
  --head stack/01-user-model \
  --title "1/3: Tilfoej User-model" \
  --body "Foerste gren i en stak paa tre PR'er. Model -> endpoint -> validering. Se #naeste-pr naar den aabnes."

Resultatet i GitHubs grænseflade er en pull request med en diff på typisk 20-40 linjer, en overskuelig størrelse, der kan godkendes på få minutter i stedet for at skulle vurderes sammen med resten af funktionen.

Du kan bekræfte, at pull requesten blev oprettet korrekt, og se dens aktuelle status direkte fra terminalen:

$ gh pr list --head "stack/*"

NO.  TITLE                        BRANCH                  BASE
1    1/3: Tilfoej User-model      stack/01-user-model      main
$ gh pr view 1 --json state,baseRefName,additions,deletions
{
  "state": "OPEN",
  "baseRefName": "main",
  "additions": 28,
  "deletions": 0
}

Trin 6: Byg den næste gren oven på den forrige, ikke på main

Her er det afgørende trin, de fleste overser første gang: den næste gren i stakken skal udgå fra den forrige gren, ikke fra main. Gør du det forkert, mangler din anden pull request den første gren’ s ændringer, og diffen bliver rodet.

git checkout stack/01-user-model
git checkout -b stack/02-user-endpoint
# Bed Copilot generere src/routes/users.js, der importerer modellen fra trin 4
git add src/routes/users.js
git commit -m "feat: tilfoej GET/POST endpoint for brugere"
git push -u origin stack/02-user-endpoint

gh pr create \
  --base stack/01-user-model \
  --head stack/02-user-endpoint \
  --title "2/3: Tilfoej bruger-endpoint" \
  --body "Bygger oven paa #1. Kraever at foerste PR er merget foerst, eller review den i kontekst af basen."

Gentag samme mønster for det tredje lag, valideringsmiddlewaren, med --base stack/02-user-endpoint. Du har nu en fuld stak på tre pull requests, hver med en afgrænset, gennemgåelig diff.

Trin 7: Kør secret-scanning, før du beder om review

GitHubs purpose-built model til at opdage lækkede secrets kører automatisk på push, hvis du har aktiveret secret-scanning i trin 1, men du bør også tilføje et simpelt tjek i et GitHub Actions-workflow, så du fanger problemer lokalt i CI, før en pull request overhovedet når en menneskelig reviewer:

# .github/workflows/pre-review-checks.yml
name: Pre-review checks
on:
  pull_request:
    branches: [main, 'stack/**']
jobs:
  checks:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Secret scanning (push protection status)
        run: gh api repos/${{ github.repository }}/secret-scanning/alerts --jq '.[] | select(.state=="open")'
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm install
      - run: npm test

Dette workflow kører på hver gren i stakken for sig, hvilket betyder, at hvis Copilot ved et uheld har skrevet en testnøgle eller et API-token ind i en enkelt gren, bliver det fanget ved netop den gren, ikke gemt et sted midt i en kæmpe samlet diff.

Trin 8: Udløs Copilot code review automatisk på hver gren

GitHubs oktober-changelog beskriver, at Copilot code review fik API-støtte og et nyt standard-effort-niveau i samme udgivelsescyklus som stacked pull requests, ifølge GitHubs egen changelog. Det betyder, du kan bede Copilot om at gennemgå hver gren i stakken programmatisk, i stedet for at skulle klikke “Request review” manuelt på hver enkelt pull request:

for pr in $(gh pr list --head "stack/*" --json number --jq '.[].number'); do
  gh api \
    --method POST \
    repos/dit-brugernavn/stacked-pr-demo/pulls/$pr/requested_reviewers \
    -f "reviewers[]=copilot"
done

Hvis dit team allerede har en dedikeret opsætning af Copilot code review med egne regler for, hvilke filtyper der skal have ekstra opmærksomhed, er det den samme konfiguration, der gælder her. Stakningen ændrer ikke på, hvordan selve code review-funktionen virker, den ændrer kun, hvor meget kode Copilot skal forholde sig til i hver omgang.

Trin 9: Ret kommentarer og synkroniser resten af stakken

Når Copilot eller en menneskelig reviewer kommenterer på gren 1, skal du rette direkte på den gren og derefter synkronisere ændringerne ned gennem resten af stakken. Git’s rebase --update-refs gør dette i ét kommando, hvis dine grene allerede er sat op som en lineær kæde:

git checkout stack/01-user-model
# ret koden baseret paa review-kommentarer
git add src/models/user.js
git commit -m "fix: tilfoej e-mail-validering efter review"

git checkout stack/03-user-validation
git rebase --update-refs stack/01-user-model
git push --force-with-lease origin stack/01-user-model stack/02-user-endpoint stack/03-user-validation

Brug altid --force-with-lease og ikke --force, når du pusher efter en rebase. Det forhindrer dig i ved et uheld at overskrive ændringer, en kollega har pushet til samme gren, mens du selv arbejdede lokalt.

Trin 10: Flet stakken i rigtig rækkefølge

Merge altid fra bunden af stakken og opad. Når den første pull request merges til main, opdaterer GitHub automatisk base-grenen for den næste pull request i kæden, så den nu peger mod main i stedet for mod den gren, der lige blev slettet:

gh pr merge stack/01-user-model --squash --delete-branch
# GitHub opdaterer automatisk base for stack/02-user-endpoint til "main"
gh pr merge stack/02-user-endpoint --squash --delete-branch
gh pr merge stack/03-user-validation --squash --delete-branch

Vælg --squash, hvis du vil have en ren historik med ét commit pr. lag i stakken. Vælg almindelig merge, hvis du har brug for at bevare hver enkelt commit, Copilot lavede undervejs, til fejlsøgning senere.

Trin 11: Ryd op og verificér, at main stadig virker

Når hele stakken er merget, skal du trække main lokalt og køre testsuiten én sidste gang, for at bekræfte at de tre lag faktisk fungerer sammen, nu hvor de er samlet igen:

git checkout main
git pull origin main
npm test
git branch -D stack/01-user-model stack/02-user-endpoint stack/03-user-validation

Dette trin springes ofte over, fordi hver enkelt pull request allerede er blevet testet isoleret. Men en fejl, der kun opstår, når alle tre lag er samlet, for eksempel et navnekonflikt mellem to lag, som agenten ikke kunne se, da den kun arbejdede på ét lag i sin egen gren, bliver kun fanget her.

Trin 12: Automatisér workflowet, så næste stak går hurtigere

Når du har kørt processen manuelt én gang, kan du gemme navngivningsmønsteret og PR-skabelonen som en reusable instruktion til Copilot. Opret en fil i repositoriet, der beskriver reglen for teamet:

# .github/copilot-instructions.md
Naar du implementerer en multi-lag feature:
1. Opdel altid arbejdet i grene med praefikset "stack/NN-beskrivelse"
2. Hver gren skal have sin egen pull request med base sat til den foregaaende gren
3. Hver PR-titel skal angive position i stakken, fx "2/3: ..."
4. Koer "npm test" lokalt foer hver commit
5. Skriv aldrig secrets, API-noegler eller tokens direkte i kildekoden

GitHub introducerede samtidig dynamiske workflows i Copilot CLI og Copilot-appen i oktober 2026, hvilket gør det muligt at definere netop denne slags gentagne instruktioner som en fast kommando, du kan genbruge på tværs af features, i stedet for at skrive planen i chatten hver gang.

5 almindelige fejl, når du stakker AI-genereret kode

At lade agenten skrive hele funktionen i én gren og forsøge at skære den op bagefter. Det er markant sværere at splitte en færdig, sammenflettet diff end at bede agenten arbejde lag for lag fra starten, som beskrevet i trin 3.
At basere den næste gren på main i stedet for på den forrige gren. Resultatet er en pull request, der viser hele den akkumulerede diff igen, hvilket ødelægger hele pointen med stakning.
At bruge git push --force efter en rebase. Det kan overskrive en kollegas arbejde uden varsel. Brug altid --force-with-lease.
At merge grenene i forkert rækkefølge. Hvis du merger gren 2, før gren 1 er merget, mister GitHub muligheden for at opdatere baserne automatisk, og du ender med manuelle konfliktløsninger.
At glemme at køre testsuiten på hele stakken samlet, efter sidste merge. Isolerede tests på hver gren fanger ikke integrationsfejl mellem lagene, som kun opstår, når alt er samlet på main.

Fejlfinding: 8 typiske problemer og løsninger

Problem: “This branch has conflicts that must be resolved” på en gren langt oppe i stakken. Løsning: Rebase fra bunden af stakken og brug --update-refs, så konflikter løses én gang og automatisk propagerer opad gennem resten af kæden.

Problem: En pull request viser pludselig ændringer fra en gren, du troede var merget. Løsning: Tjek at basen faktisk blev opdateret af GitHub efter merge med gh pr view --json baseRefName. Hvis opdateringen ikke slog igennem, skal du manuelt ændre base med gh pr edit --base main.

Problem: Copilot code review kommenterer det samme problem på flere grene i stakken. Løsning: Det er ofte fordi roden til problemet ligger i den første gren og forplantes nedad. Ret kun i gren 1, og lad rebase-trinnet i trin 9 sprede rettelsen.

Problem: git push --force-with-lease bliver afvist med “stale info”. Løsning: Nogen andre har pushet til grenen, siden du sidst hentede den. Kør git fetch origin og gentag rebase-processen, før du forcerer push igen.

Problem: Secret-scanning blokerer et push, selv om du er sikker på, der ikke er secrets i koden. Løsning: Tjek om det er en falsk positiv i en tests-fixture eller et eksempel i en kommentar. Brug gh api repos/:owner/:repo/secret-scanning/alerts for at se den konkrete alert, og marker den som “false positive” i stedet for at deaktivere scanningen helt.

Problem: Testene fejler på gren 2, selv om de kørte fint isoleret på gren 1. Løsning: Gren 2 mangler ofte en afhængighed, der kun blev installeret lokalt, ikke committet. Kør npm ci i stedet for npm install i CI for at sikre, at lockfilen er i sync.

Problem: GitHub viser stakken i forkert rækkefølge i oversigten. Løsning: Dette sker typisk, hvis en gren blev oprettet fra en forkert base fra starten. Brug gh pr edit [nummer] --base [korrekt-gren] til at rette rækkefølgen, uden at du behøver oprette pull requesten igen.

Problem: En AI-agent foreslår at committe direkte til main for at “spare tid”. Løsning: Slå branch protection til på main, så direkte push blokeres for alle, inklusive agenter, der kører med dine lokale adgangsrettigheder. Det er den samme beskyttelse, lokal sandboxing i Copilot CLI er designet til at understøtte, ved at begrænse, hvilke filer og netværk en agent kan røre.

Problem: Du har svært ved at huske, hvilken gren der er base for hvilken, efter et par dages pause fra opgaven. Løsning: Brug gh pr list --json number,headRefName,baseRefName til at få et maskinlæsbart overblik over hele stakkens struktur i et enkelt kald, i stedet for at klikke dig gennem hver pull request i browseren for at huske rækkefølgen.

Avancerede tips til teams med flere AI-agenter i gang samtidig

Når flere udviklere i samme team lader AI-agenter arbejde parallelt, bliver navngivning af stakke endnu vigtigere. Et mønster, der fungerer godt i praksis, er at inkludere udviklerens initialer i grenprefikset, for eksempel stack/mj-01-user-model, så to personers stakke aldrig kan blandes sammen i GitHubs oversigt ved et tastefejl.

Hold hver stak kort. Erfaringen fra teams, der har kørt dette workflow siden sandboxing og stacked pull requests blev generelt tilgængelige i oktober 2026, er, at tre til fem grene pr. stak er et praktisk maksimum. Går en stak længere end det, bliver den svær at holde styr på mentalt, og fordelen ved de små diffs bliver opvejet af kompleksiteten i at huske rækkefølgen.

Brug Copilots nye effort-niveauer i code review strategisk. Sæt et lavere effort-niveau på de tidlige, mindre kritiske lag i en stak, som rene datamodeller, og reservér det højeste niveau til det lag, der rammer autentificering, betalinger eller anden forretningskritisk logik. Det holder både ventetiden og udgifterne nede uden at gå på kompromis med sikkerheden, hvor det betyder mest.

Kombinér endelig stakningen med den lokale sandboxing i Copilot CLI, hvis din agent skal køre test-kommandoer, pakkehåndtering eller lokale services som en del af arbejdet. Sandboxen begrænser agentens adgang til filer, netværk og credentials, mens den arbejder, hvilket betyder, at selv hvis agenten laver en fejl i en af de tidlige grene, er skaden begrænset til det, den faktisk havde adgang til.

Mål også gevinsten. Før du ruller workflowet ud til hele teamet, kan du simpelt tracke to tal over et par uger: tiden fra en pull request åbnes til den får sin første kommentar, og den gennemsnitlige diff-størrelse pr. pull request. Begge tal kan trækkes direkte fra GitHubs API med gh api repos/:owner/:repo/pulls, og de giver et konkret, internt bevis på, om stakning rent faktisk gør reviewprocessen hurtigere i jeres specifikke kodebase, i stedet for at skulle stole blindt på generelle tal fra undersøgelser.

Overvej også at kombinere stakningen med en CODEOWNERS-fil, hvis forskellige lag i jeres applikation hører til forskellige teams. Fordi hver gren i stakken typisk rammer ét afgrænset område af kodebasen, modellen i src/models, routerne i src/routes og middleware separat i vores eksempel, kan GitHub automatisk foreslå den rigtige reviewer til netop det lag, i stedet for at hele teamet skal forholde sig til hele funktionen på én gang.

GitHubs funktionsudrulning i oktober 2026: hvad hænger sammen med hvad

Det er nemt at blive forvirret over, hvilke funktioner der hører sammen, når GitHub og VS Code ruller flere ting ud i samme periode. Her er et overblik over, hvordan de enkelte dele fra oktober 2026-udgivelsescyklussen passer ind i workflowet fra denne guide:

Funktion	Status i oktober 2026	Bruges i dette workflow
Stacked pull requests	Generelt tilgængelig	Selve stak-strukturen, trin 4 til 10
Lokal sandboxing (Copilot CLI, Copilot-app, VS Code Agent Host)	Generelt tilgængelig	Begrænser agentens filadgang under generering
Purpose-built model til lækkede secrets	Rullet ud	Trin 1 og 7, automatisk scanning af hver gren
Copilot code review API og nyt effort-niveau	Udgivet	Trin 8, programmatisk tildeling af review
Dynamiske workflows i Copilot CLI/app	Introduceret	Trin 12, genbrugelige instruktioner
VS Code 1.136 til 1.140 (agent-drevet udvikling)	Udgivet gennem september 2026	Editor-grundlaget for hele forløbet fra implementering til merge

Komplet eksempel: fra agent-prompt til merget main

Sådan ser hele forløbet ud samlet, fra første prompt til den sidste merge, for vores eksempelprojekt med bruger-model, endpoint og validering:

Agenten planlægger tre lag ud fra prompten i trin 3.
Gren stack/01-user-model oprettes fra main, Copilot skriver modellen, pull request 1/3 åbnes.
Gren stack/02-user-endpoint oprettes fra gren 1, Copilot skriver endpointet, pull request 2/3 åbnes med base sat til gren 1.
Gren stack/03-user-validation oprettes fra gren 2, Copilot skriver middlewaren, pull request 3/3 åbnes med base sat til gren 2.
Secret-scanning og testsuiten kører automatisk via GitHub Actions på alle tre grene.
Copilot code review tildeles programmatisk på alle tre pull requests.
Reviewkommentarer rettes på gren 1, og rebase --update-refs spreder rettelsen til gren 2 og 3.
Grenene merges i rækkefølge: 1, derefter 2, derefter 3, med automatisk opdatering af base mellem hver merge.
Main trækkes lokalt, og testsuiten køres en sidste gang for at bekræfte, at alle tre lag fungerer korrekt sammen.

Output efter sidste merge ser typisk sådan ud i terminalen, hvis alt er gået som planlagt:

$ npm test

> [email protected] test
> node --test

# tests 7
# pass 7
# fail 0
# duration_ms 182.4

$ git log --oneline -3
a1b2c3d feat: tilfoej valideringsmiddleware (#3)
e4f5g6h feat: tilfoej bruger-endpoint (#2)
i7j8k9l feat: tilfoej User-model med felter og typer (#1)

Stacked pull requests vs. traditionelt workflow: hvad ændrer sig i praksis

Den mest direkte forandring er, hvor hurtigt den første del af en funktion kan komme i produktion. I et traditionelt workflow venter hele funktionen på, at den sidste linje kode er skrevet, før reviewprocessen overhovedet starter. Med en stak kan datamodellen i vores eksempel merges til main, mens Copilot stadig arbejder på valideringsmiddlewaren i en senere gren.

Det ændrer også, hvem der reelt kan give meningsfuld feedback. Microsofts eget changelog for VS Code bekræfter, at september-udgivelserne (version 1.136 til 1.140) var fokuseret på netop at strømline agent-drevet udvikling fra implementering til pull request-merge (Microsoft Developer), hvilket understøtter samme tendens: mindre, hyppigere reviews giver reviewere mulighed for faktisk at forstå, hvad de godkender, i stedet for at skimme en kæmpe diff og stole blindt på, at testene fanger resten.

Ulempen er, at stakning kræver mere disciplin omkring Git end et enkelt branch-og-merge-flow. Teams, der ikke allerede er fortrolige med rebase, bør starte med korte stakke på to til tre grene, før de forsøger sig med længere kæder. Sæt gerne en intern tommelfingerregel: hvis en udvikler skal bruge mere end fem minutter på at forklare, hvorfor en gren ligger, hvor den gør, er stakken sandsynligvis blevet for kompleks, og funktionen bør i stedet deles op i to selvstændige leverancer med egen planlægning. Digital Applied fandt i deres 2026-undersøgelse, at Claude Code (28 procent) og Cursor (24 procent) er de primære værktøjer for over halvdelen af respondenterne, men at de fleste udviklere reelt kører en stak af tre forskellige værktøjer samtidig, hvilket betyder, at et stakket PR-workflow skal fungere uafhængigt af, hvilken AI-agent der genererede den enkelte gren.

Ofte stillede spørgsmål om stacked pull requests

Kræver stacked pull requests en særlig GitHub-plan?
Nej. Funktionen er en del af GitHubs almindelige pull request-grænseflade og kræver ikke Enterprise eller en separat betaling. Du skal dog have Copilot Business eller Enterprise, hvis du vil bruge Copilot code review programmatisk, som beskrevet i trin 8.

Kan jeg bruge stacked pull requests uden AI-agenter overhovedet?
Ja, workflowet er lige så nyttigt til manuelt skrevet kode. Det blev oprindeligt populært blandt teams, der arbejder med meget store funktioner, længe før AI-agenter blev en del af hverdagen. AI-genereret kode gør bare behovet mere akut, fordi agenter producerer store diffs hurtigere end mennesker typisk gør.

Hvad sker der, hvis jeg merger en gren midt i stakken før de foregående?
GitHub tillader det teknisk, men det bryder kæden. De foregående, ikke-merged grene mister deres logiske sammenhæng med den merged gren, og du risikerer at skulle løse konflikter manuelt. Merge altid fra bunden af stakken og opad.

Er stacked pull requests det samme som Git worktrees?
Nej, de løser forskellige problemer. Git worktrees lader dig have flere grene tjekket ud samtidig i separate mapper på disken. Stacked pull requests handler om, hvordan grenene forholder sig til hinanden på GitHub under review, uafhængigt af hvordan du arbejder med dem lokalt.

Hvor mange grene bør en stak maksimalt have?
Der er ingen teknisk grænse fra GitHubs side, men erfaringsmæssigt bliver stakke på mere end fem til seks grene svære at overskue. Hvis din funktion kræver flere lag end det, er det ofte et tegn på, at funktionen selv bør deles op i flere, mindre leverancer.

Virker dette workflow med andre AI-agenter end GitHub Copilot?
Ja. Selve stakningen sker i Git og GitHub CLI og er helt uafhængig af, hvilken AI-agent der skrev koden i den enkelte gren. Trinene med Copilot code review og den secret-detektions-model, GitHub introducerede i oktober 2026, er specifikke for GitHubs eget økosystem, men resten af workflowet fungerer lige godt, uanset om koden kom fra Copilot, Claude Code eller en anden agent.

Hvad gør jeg, hvis en gren i stakken bliver forældet, fordi main har ændret sig meget?
Rebase hele stakken mod den opdaterede main, startende fra bunden af kæden, og brug --update-refs til at lade ændringen forplante sig gennem resten af grenene automatisk, i stedet for at rebase hver gren manuelt én for én.

Kan jeg bruge dette workflow i et privat repository på en gratis GitHub-konto?
Ja, stacked pull requests og secret-scanning for private repositories er tilgængelige uden en betalt plan. Copilot code review og de avancerede Copilot-funktioner kræver dog et aktivt Copilot-abonnement.

Skal jeg omlægge hele teamets workflow på én gang for at få noget ud af stacked pull requests?
Nej. Det giver mere mening at starte med én udvikler eller ét lille team, der tester workflowet på en håndfuld features over to til tre uger, inden I beslutter, om det skal være standarden for resten af organisationen. Fordi stakningen foregår i almindelig Git og GitHub CLI, kan de to tilgange, store PR’er og stakkede PR’er, sagtens eksistere side om side i samme repository under overgangen.