Gör ett eget kontrollprov innan du väljer när Copilot ska granska. Anteckna både inställningen och vilken händelse du skapade. En tom fyndlista räcker inte som observation: spara också länken till själva granskningen.
En egen inställningssida för code review
Den 23 september 2026 meddelade GitHub att de nya inställningarna är allmänt tillgängliga. Via profilen och Copilot settings finns en särskild code review-sida på alla Copilot-planer, inklusive Business och Enterprise. Automatisk granskning kan aktiveras för PR:er du skapar eller medförfattar och när en PR lämnar utkastläget. Separata val gäller utkast och nya pushar.
På samma sida väljer du personlig standard för review effort, för närvarande Lite eller Balanced. Den gäller granskningar du begär, även automatiska granskningar av din PR. Under Reviewers kan du välja en annan nivå vid en manuell begäran. Behöriga enterprise-administratörer kan dessutom välja Lite, Balanced eller GitHubs standard för organisationernas repositories; organisationer och repositories kan göra egna överstyrningar. Det framgår av samma daterade GitHub-post.
Förbered ett prov där orsaken går att följa
Metoden nedan är AI-kreatörs förslag, inte ett utfört produkttest. Använd ett avgränsat testrepository och en liten kodändring som du själv förstår. Välj exempelvis en funktion som formaterar ett namn och ett tillhörande test. Poängen är att känna igen vilken commit granskningen gäller, inte att provocera fram ett bestämt antal kommentarer.
Skriv ett protokoll innan du börjar. Ge varje körning ett id, till exempel review-trigger-A. Anteckna konto, plan, repository, PR-nummer, målbranch och aktuell commit-SHA. Spara en skärmbild av de personliga inställningarna samt de organisations- och repositoryinställningar du kan läsa. Om en nivå inte är åtkomlig skriver du det uttryckligen. Du kan då avgränsa slutsatsen till den konfiguration du faktiskt såg.
Undvik att samtidigt testa medförfattarskap, flera konton och olika repositories. Börja med en PR du själv skapar. Gör medförfattarskap till en separat upprepning med eget körnings-id, där även vem som skapade PR:n och vem som medförfattade dokumenteras. Annars kan en lyckad körning tillskrivas fel persons inställningar.
Matris: en händelse i taget
Tabellen är ett arbetsblad med provfrågor. Fyll själv i observerat utfall; inga rader är förhandsmarkerade som godkända. Utgångsläget är att automatisk granskning är på, medan granskning av utkast och nya pushar är av. Välj samma personliga effort-nivå genom hela första omgången. Inställningsnamnen och möjligheterna kommer från GitHubs besked den 23 september; ordningen och bedömningsmetoden är redaktionella förslag.
| Prov | Inställning och handling | Fråga att pröva | Observerat utfall att fylla i |
|---|---|---|---|
| A: utkast | Skapa PR:n som utkast med utkastgranskning av. | Syns någon granskning trots detta? | Ingen observerad / begärd / klar / fel, plus tid och länk. |
| B: redo | Behåll inställningarna. Flytta samma PR till redo för granskning. | Startar en granskning vid övergången? | Status, commit-SHA och länk till granskningen. |
| C: ny push, av | Vänta in föregående körning. Pusha en liten kodändring med pushgranskning av. | Tillkommer en ny granskning? | Ny granskningslänk eller ingen observerad under mätfönstret. |
| D: ny push, på | Aktivera pushgranskning. Spara inställningen och pusha nästa kodändring. | Skiljer sig utfallet från C? | Tid för inställning, push och eventuell ny granskning. |
| E: manuellt | Begär granskning via Reviewers och välj den andra effort-nivån. | Vilket val registrerade du vid begäran? | Vald nivå, begärans tid och granskningslänk. |
| F: utkast, på | Skapa en ny test-PR som utkast med utkastgranskning på. | Skiljer sig utfallet från A? | PR-nummer, inställningar och observerad granskningsstatus. |
Återanvänd gärna samma lilla exempeländring i A och F men skapa separata PR:er från en dokumenterad startcommit. Då har du ett jämförbart par. Att slå på ett val efter att utkastet redan skapats prövar en annan fråga: om en ändrad inställning ensam utlöser något retroaktivt. Blanda inte det försöket med provet för en ny PR.
Logga väntan utan att uppfinna en tidsgräns
Bestäm ett observationsfönster innan varje steg, exempelvis tio minuter. Det är ditt mätval, inte ett löfte från GitHub om svarstid. Anteckna starttid och sluttid med tidszon. Om inget syns när fönstret stängs skriver du ”ingen granskning observerad inom tio minuter”, inte ”funktionen startar aldrig”. Behåll PR:n så att en senare körning går att hänföra till rätt händelse.
Vänta tills en pågående granskning är färdig eller har ett dokumenterat fel innan du gör nästa push. Spara både SHA före och efter ändringen. Om PR:n redan har en granskningskommentar ska du inte räkna dess närvaro som bevis för en ny körning. Leta efter en separat händelse, tidsstämpel eller granskningslänk som du kan koppla till det aktuella steget.
Skilj också på begärd granskning, färdig granskning och antal fynd. Ett protokoll med ”klart, noll kommentarer” säger något annat än ”ingen körning observerad”. Använd dessa statusar konsekvent i alla rader. Du kan då jämföra utlösarna utan att samtidigt försöka mäta kodgranskningens träffsäkerhet.
Kontrollera effort separat från utlösaren
Gör först klart händelseprovet med en fast personlig nivå. Byt sedan nivå för det manuella steget och spara valet innan du skickar begäran. Om resultatvyn inte visar vilken nivå som användes skriver du ”vald nivå dokumenterad, använd nivå ej synlig”. Härled inte Lite eller Balanced från hur många kommentarer du fick eller hur lång tid körningen tog.
För ett organisationsägt repository bör du be den som kan läsa konfigurationen att dokumentera enterprise-, organisations- och repositorynivån vid samma tidpunkt. Artikeln gör inget antagande om en fullständig prioritetsordning mellan alla personliga val och ärvda inställningar. Om de pekar åt olika håll behöver du ett särskilt prov och tydligare underlag innan du beskriver vilket värde som vann.
Låt kostnadsfrågan få en egen kontrollpunkt i genomgången av Copilots policy och fakturering. För räckvidden på stora eller botskapade ändringar finns artikeln om stora bot-PR:er. Det håller den här matrisen fokuserad på när en granskning begärs och vilket val du gjorde.
Vad du ska kunna lämna till en kollega
Efter provet bör en kollega kunna följa varje rad från inställningsbild via PR-händelse till utfall. Markera en rad som avvikande om du ser en körning som du inte kan förklara med den dokumenterade konfigurationen. Upprepa då just den raden på en ny PR med samma startcommit och färre samtidiga förändringar. Skriv kvar det första utfallet i protokollet så att omprovet inte suddar ut observationen.
Välj därefter ett arbetssätt utifrån hur ofta du vill få återkoppling under utkast och efter nya ändringar. Dokumentera vem som äger inställningen och när provet ska upprepas. När själva körkedjan är klar kan du gå vidare till hur du läser Copilots fynd och resolutionsskäl. Det är en separat granskningsuppgift med andra observationer.
Källor
- GitHub Changelog: More ways to request and configure Copilot code reviews – 23 september 2026. Inställningssida, utlösare, personligt effort-val och enterprise-standard.
Primärkällan kontrollerades den 24 september 2026. Matrisen och protokollet är AI-kreatörs föreslagna metod. Inga egna körresultat redovisas.