Sedan den 18 september 2026 löser Copilot code review egna kommentarer med skälet Won't Fix eller Incorrect utifrån dina senare commits, och respekterar ett svar som ber att lämna fyndet öppet. Läs Previously missed som ett mått på vad den förra granskningen inte såg, och behandla ett botsatt skäl som en signal att granska, inte som ett fattat beslut. Kör provet nedan innan du litar på att branchregeln fortfarande betyder det du tror.
Vad som ändrades den 18 september
I en changelogpost den 18 september 2026 beskriver GitHub tre förändringar i Copilot code review. Överblickskommentaren grupperar nu fynden i tre kategorier: Open för sådant som inte har hanterats, där nyligen introducerade problem kan märkas new; Resolved since last review där Copilot har validerat att du åtgärdat tidigare fynd; och Previously missed, som GitHub definierar som ”issues not introduced by a new commit, but newly found in your existing changes by Copilot's subsequent review”. Varje kommentar får dessutom en beskrivande titel.
Den andra förändringen gäller automatisk lösning av trådar. Copilot löser nu kommentarer med ett angivet skäl, antingen Won't Fix eller Incorrect, baserat på dina efterföljande commits. Får en kommentar ett svar som ber att lämna fyndet öppet respekterar Copilot det svaret. Posten säger ingenting om hur Copilot väljer mellan de två skälen, och den här artikeln påstår inte mer än så. Grunden lades i auto-resolution-posten den 11 september 2026, där kommentarer löses när en senare commit adresserar återkopplingen och kvarstående fynd förblir öppna.
Den tredje förändringen är att Copilot genererar en commit-titel och en valfri beskrivning när du committar en ”eligible, complete batch” av förslag. Vad som gör en batch eligible definieras inte i posten. Räckvidd, kostnad och policy för själva granskningen ändras inte här; det ämnet täcks i AI-kreatörs genomgång av Copilot code review för stora och botskapade pull requests.
Två nya signaler att läsa
Previously missed är ett täckningsmått för förra granskningen. Kategorin innehåller fynd i kod som redan fanns i din PR vid förra körningen men som Copilot först nu rapporterar. En PR med tre fynd under Previously missed efter en liten commit betyder att den första granskningen lämnade tre problem orapporterade, inte att din senaste commit skapade dem. GitHubs dokumentation säger uttryckligen att Copilot inte garanterat hittar alla problem i en pull request, så den här listan är inte heller fullständig. Räkna raderna per PR under en vecka. Om Previously missed ofta är tomt vid andra körningen säger det något om första körningens täckning; om det ofta är fyllt bör du inte låta en enda körning vara underlag för merge.
Ett skäl satt av boten är inte ett mänskligt beslut. När en kollega löser en tråd med Won't Fix har någon vägt fyndet mot en kostnad. När Copilot sätter samma skäl utifrån en commit finns inget sådant beslut i historiken, bara en tråd som ser färdig ut. Den svagare läsningen är att skälet är en hypotes: boten bedömer utifrån din commit att fyndet inte längre gäller eller inte stämde. Den läsningen kräver att någon i teamet tittar på skälet, särskilt när fyndet rör en klass som du inte vill låta en commit stänga tyst.
Regeln Require conversation resolution before merging kräver enligt GitHubs dokumentation att alla kommentarer på pull requesten är lösta innan den kan mergas till en skyddad branch. Dokumentationen skiljer där inte på vem som löste tråden. Vad regeln bevisade redan när Copilot började lösa trådar utan skäl beskriver AI Programming Manuals nyhet från den 14 september 2026. Om regeln i din organisation faktiskt släpper igenom en PR där den enda lösaren är Copilot ska du verifiera, inte anta.
Ett fyrstegsprov på en test-PR
Provet nedan är en föreslagen metod, inte ett utfört test. Använd ett avgränsat repository med regeln om lösta konversationer aktiverad på målbranchen, och samma effort-nivå som i drift. Skapa en PR som ger minst fyra separata Copilot-fynd, till exempel en saknad null-kontroll, en oanvänd variabel, en hårdkodad timeout och ett fel i felhanteringen i testkod. Notera att Copilot enligt dokumentationen bara granskar en PR en gång om inte granskning per push är konfigurerad, så begär en omgranskning efter varje steg och spara commit-SHA, tidpunkt och den nya överblicken.
| Steg | Åtgärd | Förväntad status per tråd | Anteckna |
|---|---|---|---|
| 1 | Fixa fynd A fullständigt i en commit | Tråden löses av Copilot och hamnar under Resolved since last review | Vem står som lösare, visas ett skäl |
| 2 | Rör inte fynd B | Tråden förblir Open | Om B ändå får ett skäl är det ett avvikande resultat |
| 3 | Svara på fynd C att det ska hållas öppet och ändra sedan kod i samma fil | Tråden förblir Open trots commit | Exakt ordval i svaret, eftersom källan inte anger vilken formulering som krävs |
| 4 | Fixa fynd D delvis, till exempel en av två kodvägar | Okänt: antingen Open eller löst med Won't Fix eller Incorrect | Det här är provets viktigaste rad |
Efter sista omgranskningen dokumenterar du tre saker. För det första listan under Previously missed: den visar vad den första körningen inte såg i kod du inte rört. För det andra merge-knappens tillstånd när enbart botlösta trådar återstår, alltså efter steg 1 och 4 om steg 4 löstes: om knappen är aktiv släpper regeln botstängda trådar i din konfiguration. För det tredje vad som hände med tråd C: om den stängdes trots svaret vet du att ordvalet i svaret spelar roll och behöver standardiseras i teamet.
En regel för skäl som alltid eskaleras
Bestäm före provet vilka fyndklasser som aldrig får stängas av ett botsatt skäl utan mänsklig bekräftelse. En användbar startlista är autentisering, hemligheter och nycklar, indatavalidering och behörighetskontroller – samma klasser som AI-kreatörs sju frågor per diff ber dig ställa oavsett vem som skrev koden. För sådana fynd betyder ett Won't Fix eller Incorrect från Copilot att tråden öppnas igen av en människa, som antingen bekräftar skälet i ett eget svar eller åtgärdar koden. Det är AI-kreatörs arbetssätt, inte ett GitHub-krav. Kravet från GitHub är det generella: validera Copilots återkoppling noggrant och komplettera med mänsklig granskning.
Skriv regeln så att den kan kontrolleras i efterhand. ”Ingen PR som rör auth/ mergas med en Copilot-löst tråd utan ett mänskligt svar i tråden” går att granska i PR-historiken. ”Vi tittar alltid noga på säkerhetsfynd” gör det inte. Om provet visar att branchregeln släpper botstängda trådar behöver regeln också en teknisk komponent, till exempel att en person begär omgranskning och läser skälen innan godkännande ges.
Källor
- GitHub Changelog: Copilot code review: An improved review experience – publiceringsdatum, de tre grupperna, definitionen av Previously missed, skälen Won't Fix och Incorrect, svar som håller fynd öppna och genererade commit-meddelanden.
- GitHub Changelog: Auto-resolution and analysis updates in Copilot code review – att kommentarer löses vid omgranskning när en senare commit adresserar dem och att kvarstående fynd förblir öppna.
- GitHub Docs: About GitHub Copilot code review – att en PR granskas en gång om inte granskning per push är konfigurerad, samt att Copilot inte garanterat hittar alla problem och ska kompletteras med mänsklig granskning.
- GitHub Docs: About protected branches – vad regeln Require conversation resolution before merging kräver.
Uppgifterna kontrollerades mot GitHubs primärkällor den 19 september 2026. Fyrstegsprovet, läsningen av Previously missed som täckningsmått och eskaleringsregeln är AI-kreatörs metod, inte GitHub-krav.