Definiera en basfråga för öppna, granskningsbara och AI-märkta pull requests. Dela den som text, inte som en persons webbläsarläge. Läs sedan varje träff i samma ordning: statuskontroller, stackindikator, olästa uppdateringar och diffens risk. Använd massåtgärder för etiketter och milstolpar. Låt branch protection, obligatoriska granskningar och CI avgöra om en ändring får slås samman.
Vad GitHub faktiskt har ändrat
GitHub meddelade den 21 september 2026 att den uppdaterade PR-sidan på repositorynivå var allmänt tillgänglig. Den har innehållsassistent för filter, avancerad sökning med AND, OR och nästlade uttryck, hopfällbar sidopanel samt ett kompakt läge. Raderna visar dessutom antal statuskontroller, om en PR ingår i en stack och om det finns olästa uppdateringar.
Det gör listan bättre som inkorg. Det gör den inte till en ny sorts godkännandemotor. Ett antal gröna kontroller säger exempelvis inget om huruvida just de kontrollerna är obligatoriska, kördes mot rätt revision eller om en gammal granskning blivit inaktuell efter en ny push. Listan hjälper dig att hitta vad som kräver uppmärksamhet; detaljvyn och repositoryreglerna avgör vad signalen betyder.
Börja med en ködefinition som går att reproducera
En granskningskö är först reproducerbar när en kollega kan klistra in samma fråga och få samma avgränsning. Börja därför med tre beslut som teamet äger: vilken etikett markerar AI-assisterat arbete, vilka statusar räknas som granskningsbara och vilka basgrenar ingår. Ett praktiskt exempel är en kö för öppna PR:er mot main, med etiketten ai-assisted, som inte är utkast.
Namn: AI-granskning – redo för människa
Bas: öppna PR:er mot main, etikett ai-assisted, utkast bortfiltrerade
Prioritet: felande eller pågående kontroller först, därefter stackade PR:er, sedan olästa uppdateringar
Ägare: dagens reviewer; frågan sparas i teamets dokumentation
Använd GitHubs innehållsassistent för att välja rätt fältnamn och bygg sammansatta villkor med sökfältets operatorer. Kopiera sedan det färdiga uttrycket till exempelvis CONTRIBUTING.md eller teamets granskningsrutin. Dokumentera även vad etiketten betyder. Om en bot sätter ai-assisted automatiskt ska regeln vara synlig; annars kommer kön att missa ändringar utan att någon märker det.
Läs tre risksignaler i fast ordning
1. Statusräkningen. Öppna alla rader där kontroller saknas, körs eller är röda. Kontrollera namnen i mergeboxen och den revision de gäller. En rå räknare kan prioritera arbetet, men den ersätter inte läsning av den obligatoriska kontrollens utfall.
2. Stackindikatorn. En staplad ändring kan vara liten isolerat men bero på en lägre PR. Börja längst ned i stacken och skriv upp basen för varje steg. Om en underliggande diff ändras efter granskning ska de ovanför återkontrolleras mot den nya basen. Markören är alltså en varning om granskningsordning, inte ett löfte om att beroendena är stabila.
3. Olästa uppdateringar. Behandla indikatorn som en återöppnad uppgift. Läs först vad som ändrats sedan din senaste genomgång: nya commits, ny kommentar, omkörd kontroll eller ändrad etikett. Vid ny kod ska du börja om vid den ändrade diffen och verifiera att tidigare slutsatser fortfarande gäller. Särskilt AI-genererade följdändringar kan vara välformulerade men bredare än granskarens ursprungliga begäran.
Den fasta ordningen hindrar en visuellt ren rad från att hoppa före en PR med blockerad CI eller osäker bas. För själva diffen kan du sedan använda AI-kreatörs sju frågor för AI-genererad kod: förklara varje rad, kontrollera uppgiftens gräns och kräv ett körbart bevis.
Håll massåtgärderna till metadata
Den nya sidan kan enligt GitHub utföra massåtgärder på en eller flera pull requests, bland annat stänga dem, sätta etiketter och byta milstolpe. Använd gärna flerval för reversibel metadata: lägg till needs-review, flytta en verifierad grupp till en milstolpe eller markera vilka ärenden dagens reviewer tagit. Kör åtgärden på två testposter först och kontrollera urvalet igen innan du bekräftar.
Stäng inte en grupp PR:er bara för att samma filter fångar dem. Ett filter kan vara för brett, en etikett kan vara gammal och en oläst kommentar kan innehålla ett aktivt undantag. Stängning påverkar arbetsflödet och bör därför beslutas per ärende, med synlig motivering. Merge hör inte hemma som en administrativ listoperation.
En enkel ansvarsfördelning minskar misstag: filter väljer kandidater, en människa bekräftar urvalet och bulksteget ändrar bara metadata. Därefter öppnas varje PR som ska stängas eller slås samman separat. På så sätt ger den snabba inkorgen inte en falsk känsla av att besluten också kan tas i bulk.
Verifiera den riktiga stoppregeln
GitHubs dokumentation om skyddade grenar anger att branch protection kan kräva exempelvis godkända granskningar, statuskontroller, lösta konversationer och en mergekö. Om statuskontroller är obligatoriska måste de passera innan ändringen får slås samman. Det är här stoppregeln hör hemma – inte i ett delat sökuttryck.
Gör därför ett kontrollprov på en test-PR. Låt en obligatorisk CI-kontroll misslyckas, bekräfta att PR:n syns i rätt riskkö och försök sedan inte kringgå mergeboxens blockering. Rätta felet, kör om kontrollen mot senaste commit och verifiera att grinden öppnas först när repositoryts krav är uppfyllda. En tydlig modell för vilka CI-resultat som ska blockera finns i stoppregler före merge.
En daglig rutin på sex steg
Efter en vecka kan du mäta tre enkla saker: hur många PR:er kön missade på grund av fel etikett, hur många som behövde återgranskas efter en oläst uppdatering och hur ofta en stack öppnades i fel ordning. Justera sedan kökontraktet, inte repositoryts säkerhetsregler, tills listan speglar teamets verkliga arbete.
Källor
- GitHub Changelog: Refreshed repository pull requests page generally available – datum, tillgänglighet, sökoperatorer, filterstöd, statusräkning, stack- och olästindikatorer samt namngivna massåtgärder.
- GitHub Docs: About pull requests – pull requests som arbetsyta för att föreslå, diskutera och slå samman ändringar.
- GitHub Docs: About protected branches – de repositoryregler som faktiskt kan kräva granskningar och statuskontroller före merge.
Uppgifterna kontrollerades mot GitHubs primärkällor den 22 september 2026. Kökontraktet, triageordningen, begränsningen av massåtgärder och sexstegsrutinen är AI-kreatörs föreslagna arbetsmetod, inte GitHub-krav.