GitHubin haarasuoja: yksi sääntö, rulesetissä useita

GitHubin perinteisistä haarasuojaussäännöistä vain yksi vaikuttaa samaan haaraan kerrallaan. Rulesetejä voi kohdistua samaan haaraan useita: niiden vaatimukset tulevat voimaan yhdessä, ja eri tavoin asetetuista saman säännön versioista sovelletaan tiukempaa. Ruleset sopii pää- tai julkaisuhaaraan, kun suojauksia halutaan kerrostaa ilman perinteisten sääntöjen keskinäistä etusijajärjestystä.

Turvallinen siirtyminen alkaa nykyisten vaatimusten kartoituksesta. Luo niiden pohjalta oikeisiin haaroihin kohdistuva ruleset, tarkista ohitusoikeudet ja kokeile yhdistämisen estymistä ennen vanhan haarasuojaussäännön poistamista. Siirtymän aikana vanha sääntö ja aktiivinen ruleset vaikuttavat rinnakkain, joten testin tulos on tulkittava sen mukaan.

Kartoita haaran nykyiset vaatimukset

Avaa repositorion asetuksista nykyinen haarasuojaussääntö ja kirjaa sen kohdehaarat. Merkitse muistiin pull requestin ja hyväksyntöjen vaatimukset, pakollisten tilatarkistusten täsmälliset nimet sekä se, pitääkö lähdehaaran olla ajan tasalla kohdehaaran kanssa. Tarkista myös allekirjoitetut commitit, suoran kirjoittamisen rajoitukset, poistamisen esto ja pakotetun pushin asetukset. Näin myöhempi vertailu perustuu käytössä oleviin ehtoihin eikä pelkkään säännön nimeen.

Selvitä samalla, kohdistuuko päähaaraan jo repositorion tai organisaation ruleset. Jos näin on, lisää sen ehdot kartoitukseen: uuden rulesetin luominen ei syrjäytä aiempaa. Kirjaa erikseen, ketkä voivat ohittaa nykyisen suojauksen. Tämä on tärkeää myös silloin, kun vanhan ja uuden säännön näkyvät yhdistämisehdot näyttävät samoilta.

Kohdista ruleset oikeisiin haaroihin

Luo repositorion Settings-valikossa uusi branch ruleset Rulesets-kohdan kautta. GitHubin luontiohjeen mukaan Target branches -kohdassa voi sisällyttää oletushaaran sekä lisätä tai sulkea pois haaroja nimen tai kuvion perusteella. Oletushaaran valinta on selkeä ratkaisu päähaaran suojaukseen; julkaisuhaaroille kannattaa määrittää niiden todellista nimeämistä vastaava kohdistus.

Jos julkaisuhaarat ovat esimerkiksi muotoa release/versio, kuvio release/* kattaa yhden nimitason. Se ei kata haaraa release/2026/versio, koska kohdistuksessa käytetty tähti ei ylitä kauttaviivaa. Tarkista siis erikseen sekä nykyiset että odotettavissa olevat haaranimet. Liian kapea kuvio jättää osan julkaisuhaaroista suojauksen ulkopuolelle, kun taas liian laaja kuvio voi ulottaa yhdistämisehdot muihinkin haaroihin.

Disabled-tilassa voit valmistella ja tarkastaa rulesetin ilman, että se vielä estää muutoksia. Vaihda tilaksi Active vasta, kun kohdistus ja asetukset ovat valmiit testattaviksi; aktiivinen sääntö tulee voimaan heti. Säilytä vanha haarasuojaus tämän vaiheen ajan, jotta voit verrata uuden kokonaisuuden toimintaa aiempiin vaatimuksiin.

Määritä yhdistämisen ehdot

Valitse haaralle ne ehdot, joiden on todella täytyttävä ennen yhdistämistä. GitHubin sääntöluettelo kattaa muun muassa pull requestin, hyväksytyt tilatarkistukset ja varmennetut allekirjoitetut commitit. Sen salaisuushälytyksiä koskeva yhdistämissääntö on julkisessa ennakkoversiossa ja edellyttää, että repositoriossa käytetään secret scanningia. Se voi estää yhdistämisen, jos pull requestin viimeisimmän commitin skannaus on kesken tai pull requestin commit on tuonut avoimen, rulesetissä valittuun tyyppiin kuuluvan hälytyksen.

Lisää pakollisiksi vain ne tarkistukset, joiden on valmistuttava ennen yhdistämistä, ja käytä niiden täsmällisiä nimiä. Jos tarkistuksen tuottaa GitHub App, odotetun lähteen voi rajata kyseiseen sovellukseen. Päätä myös, vaaditaanko lähdehaaran päivittäminen kohdehaaran tasalle ennen yhdistämistä. Tiukka asetus tarkistaa muutoksen ajantasaista kohdehaaraa vasten, mutta päähaaran muuttuminen voi edellyttää uusia tarkistusajoja.

Allekirjoitusvaatimus ulottuu haaralle tuleviin committeihin, ei vain lopulliseen yhdistämistoimintoon. Allekirjoittamaton commit pull requestin lähdehaarassa voi siksi estää myös squash-yhdistämisen, vaikka GitHub allekirjoittaisi lopullisen squash-commitin. Ennen vaatimuksen aktivointia varmista, että sekä kehittäjät että muutoksia tekevät automaatiot pystyvät tuottamaan varmennetut allekirjoitukset.

Rajaa ohitusoikeudet erikseen

Rulesetin Bypass list määrittää, mitkä roolit, tiimit tai GitHub Appit voivat sivuuttaa sen ehdot. Kirjoitusoikeus repositorioon ei yksin tarkoita, että toimija pitäisi lisätä ohituslistalle. Käy jokainen lisäys läpi suhteessa sen tehtävään: esimerkiksi automaation tarve päivittää haaraa ei välttämättä edellytä oikeutta ohittaa katselmointia tai pakollista tarkistusta.

Jos poikkeus on tarpeen mutta muutoksesta halutaan pull requestin jälki, valitse ohitukselle For pull requests only Always allow -asetuksen sijaan. Tämä edellyttää pull requestin avaamista, mutta toimija voi silti käyttää ohitusoikeutta yhdistämisessä. Vertaa listaa vanhan haarasuojan poikkeuksiin ja muihin samaan haaraan kohdistuviin sääntöihin, jotta tiedät, kenellä on käytännössä mahdollisuus viedä muutos päähaaraan.

Testaa esto ennen vanhan säännön poistamista

Avaa suojattuun haaraan kohdistuva testipull request, jota et yhdistä. Kokeile tavallisella käyttäjätunnuksella tilannetta, jossa nimetty pakollinen tarkistus puuttuu tai on kesken, ja varmista, että yhdistäminen estyy oikeasta syystä. Jos allekirjoitusvaatimus kuuluu suunnitelmaan, kokeile sitä erillisellä allekirjoittamattomalla testicommitilla. Salaisuushälytysten vaikutuksen voi tarkistaa repositoriossa jo olevalla soveltuvalla hälytyksellä; testiä varten ei tarvitse lisätä aitoa salaisuutta.

Kokeile myös sallittua tapausta: tavallisessa pull requestissa vaaditut tarkistukset valmistuvat, katselmoinnit täyttyvät ja commitit ovat varmennettuja. Ehdollisessa esimerkissä vanha päähaaran suojaus vaatii hyväksynnän ja uusi ruleset allekirjoitetut commitit. Niin kauan kuin molemmat ovat aktiivisia, kumpikin ehto on täytettävä. Jos ne määrittävät saman vaatimuksen eri tiukkuudella, tiukempi jää voimaan.

Poista tai muuta vanhaa haarasuojaussääntöä vasta, kun uuden rulesetin kohdistus, ehdot ja ohitukset on tarkistettu. Toista sen jälkeen sekä estyvän että sallitun yhdistämisen koe. Näin näet, johtuuko haluttu suojaus uudesta rulesetistä myös ilman vanhan säännön vaikutusta.

Lue myös: