programmatūra · 4 min · 11.07.2026

GitHub ļauj ierobežot, cik pull request var atvērt viens lietotājs bez rakstīšanas tiesībām

GitHub 17. jūnijā ieviesa iestatījumu, ar kuru repozitorija uzturētājs var noteikt, cik atvērtu pull request vienlaikus drīkst būt lietotājam bez rakstīšanas tiesībām. Kad skaitlis sasniegts, tāds lietotājs pirms jauna PR atvēršanas vecu aizver vai sapludina. Melnraksta PR uz limitu neskaitās, bet AI aģenta atvērtais gan.

Iestatījums atrisina konkrētu sāpi. 2023. gada janvārī visā GitHub mēnesī sapludināja aptuveni 25 miljonus pull request. Tagad skaitlis pārsniedz 90 miljonus, un daļa no tā ir mašīnģenerēts kods, ko iesniedzējs pats nav pārlasījis.

Kā jaunais limits strādā

Skaitli uzturētājs uzstāda repozitorija iestatījumos. Tas attiecas tikai uz lietotājiem bez rakstīšanas tiesībām — komandas locekļus tas neskar. Kad kāds sasniedz limitu, GitHub bloķē nākamā PR atvēršanu, līdz viens no esošajiem tiek aizvērts vai iekļauts kodā.

Divi nianses maina, cik agresīvi tas nostrādā. Melnraksti neskaitās, tāpēc iesāktu darbu var turēt atvērtu bez soda. Toties Copilot vai cita aģenta atvērtais PR skaitās tāpat kā cilvēka atvērtais — tieši šī plūsma pēdējā gadā uzturētājiem sagādā visvairāk troksni. Uzticamos ārējos līdzstrādniekus var pievienot apejas sarakstam (bypass list); viņi limitu pārsniedz, bet pilnas līdzstrādnieka tiesības nesaņem, kā skaidro GitHub izmaiņu žurnāls.

Kāpēc GitHub to dara tieši tagad

Skaitļu pieaugums no 25 līdz 90 miljoniem PR mēnesī nozīmē, ka atsevišķam projektam ienāk vairāk iesniegumu, nekā komanda spēj izskatīt. AutoGPT uzturētājs Nicholas Tindle GitHub emuārā stāsta, ka limits atgrieza vēlmi vispār atvērt pull request lapu, jo vairs nav sajūtas, ka viens lietotājs uzreiz iemetis piecus vai desmit nekvalitatīvus iesniegumus.

Šī funkcija ļauj mums saglabāt ārējo līdzdalību, vienlaikus noturot iesniegumu plūsmu tādā līmenī, ar ko varam tikt galā. Nicholas Tindle uzsver, ka AI to plūsmu tikai paātrināja.

Homebrew uzturētājs Mike McQuaid un OpenClaw pārstāvis Vincent Koc tajā pašā GitHub rakstā apraksta to pašu: lielie projekti spamam pretī bija spiesti būvēt paši savus botus, tāpēc iebūvēts risinājums viņiem ietaupa darbu. Kods, ko ģenerē modelis un iesniedz bez cilvēka pārbaudes, aizņem to pašu recenzenta laiku, ko īsts labojums, bet retāk atrisina īstu problēmu.

Problēma pārceļas uz issues

Pull request nav vienīgais kanāls, pa kuru ienāk troksnis. 30. jūnijā GitHub pievienoja slēdzi, kas ļauj issue izveidi atļaut tikai līdzstrādniekiem. Nākamais solis ir tādi paši limiti issues, kā PR gadījumā — cik atvērtu problēmu vienlaikus drīkst turēt lietotājs bez rakstīšanas tiesībām, ar to pašu apejas sarakstu.

Vēl gaidāmi PR arhivēšana un gudrāki apejas signāli: konta vecums, agrāk sapludināto PR skaits un piederība organizācijai. Tie ļaus atslogot ierobežojumus tiem, kam jau ir sekmju vēsture, nevis prasīt katru pievienot sarakstam ar roku. GitHub izpēta arī vairāku repozitoriju kopīgu iestatījumu, lai limitu nevajadzētu uzstādīt katrā projektā atsevišķi.

Ko tas maina uzturētājam

Kopā ar februārī pievienoto iespēju pull request kādā repozitorijā izslēgt pilnībā, uzturētājam tagad ir vairāki līmeņi starp “pieņemam visu” un “neko nepieņemam”. Var atstāt PR atvērtus, bet ierobežot skaitu vienam lietotājam; var ielaist tikai uzaicinātos; var izslēgt PR un atstāt tikai issues.

Praksē noklusējuma skaitli GitHub neuzspiež — uzturētājs to izvēlas pats atkarībā no tā, cik recenzentu ir un cik iesniegumu komanda spēj izlasīt. Maziem projektiem ar vienu uzturētāju stingrs limits nogriež spamu ātri; lieliem projektiem, kur ārējā līdzdalība ir vērtība, apejas saraksts un vēstures signāli ļauj palaist iekšā tos, kam var uzticēties. Iestatījums pieejams visiem publiskajiem repozitorijiem jau tagad.

Avoti

komentārisaruna

Komentāri

Šim rakstam vēl nav komentāru. Esi pirmais, kurš dalās ar savu viedokli.

Pievieno komentāru

Tavs e-pasts netiks publicēts. Obligātie lauki atzīmēti.

vēl no programmatūrasaistītie