Protejezi ramura principală pe GitHub? Ruleset-ul evită regula care se pierde

Pentru a proteja ramura principală pe GitHub, creează un branch ruleset care vizează ramura implicită, cere un pull request aprobat și verificări CI trecute, apoi blochează ștergerea și push-urile forțate. Lasă lista de bypass goală dacă nu ai nevoie de excepții. Regulile de suprapunere GitHub arată de ce această alegere este utilă: mai multe rulesets se pot aplica aceleiași ramuri, în timp ce dintre regulile clasice de branch protection se aplică una singură.

În Settings → Rulesets → Rulesets, alege New ruleset → New branch ruleset, include ramura implicită la Target branches și selectează protecțiile. Stabilește explicit câte aprobări și ce verificări ceri, revizuiește Bypass list, apoi pune ruleset-ul în starea Active. Starea aleasă contează: un ruleset lăsat Disabled nu protejează ramura.

De ce poate lipsi o regulă clasică din protecția efectivă

Imaginează-ți două reguli clasice care corespund ramurii main: una vizează numele exact, cealaltă un tipar mai larg. Administratorul le poate vedea pe amândouă în setări și poate presupune că cerințele lor se adună. GitHub aplică însă numai una dintre regulile clasice potrivite. Regula rămasă în listă nu este ștearsă, dar cerințele ei nu devin automat parte din protecția ramurii.

Rulesets rezolvă această ambiguitate prin cumularea regulilor aplicabile, fără o prioritate dată de ordinea creării. Dacă un ruleset cere recenzii, iar altul verificări de stare, ramura trebuie să îndeplinească ambele cerințe. Când aceeași condiție este definită diferit în rulesets suprapuse, se aplică varianta mai restrictivă. O regulă clasică încă activă participă și ea la protecție; înainte de migrare, verifică ce condiții impune, ca să nu păstrezi fără intenție un blocaj.

Pașii pentru un branch ruleset activ

Poți crea sau modifica rulesets dacă ai acces de administrator la depozit ori un rol personalizat cu permisiunea de editare a regulilor. Disponibilitatea depinde de plan și de vizibilitatea depozitului: rulesets sunt disponibile pentru depozite publice pe GitHub Free și pentru depozite publice sau private pe GitHub Pro, Team și Enterprise Cloud. Instrucțiunile GitHub de creare descriu selecția țintei, a excepțiilor și a stării de aplicare.

1. Dă ruleset-ului un nume descriptiv. La Target branches, folosește Add a target și include ramura implicită. Alegerea vizează rolul ramurii principale; un tipar literal main vizează numai ramura cu acel nume.
2. Activează Require a pull request before merging și stabilește numărul de aprobări necesare. Cerința de pull request, singură, obligă deschiderea lui, dar nu cere și aprobarea.
3. Activează Require status checks to pass before merging. Adaugă verificările CI după numele cu care apar ca rezultate ale joburilor și confirmă fiecare intrare în interfață.
4. Verifică Restrict deletions și Block force pushes pentru ramura vizată. Prima împiedică ștergerea de către actorii fără bypass; a doua oprește rescrierea forțată a istoricului.
5. Revizuiește Bypass list, selectează Active și apasă Create. Un ruleset activ se aplică imediat după creare.

Aceste setări aparțin unui branch ruleset, potrivit pentru controlul actualizărilor ramurii și al îmbinărilor. Un push ruleset servește alt scop: poate restricționa, de exemplu, căi de fișiere, extensii ori dimensiuni și se aplică rețelei de forkuri a depozitului. Pentru aprobările și verificările cerute înainte de îmbinarea în main, ținta este ramura.

Două configurații reproductibile

Proiect mic

Ca exemplu de politică pentru un proiect mic, presupune că un job CI stabil apare în pull request sub numele tests. Vizează ramura implicită, cere un pull request, o aprobare și rezultatul trecut al verificării tests. Păstrează blocarea ștergerii și a push-urilor forțate și nu adăuga bypass. Astfel, fiecare schimbare obișnuită are o recenzie și un rezultat CI înainte de îmbinare.

Dacă jobul nu rulează încă pentru pull requesturi, nu introduce un nume ghicit drept verificare obligatorie. Pornește fluxul CI și identifică rezultatul pe care GitHub îl afișează efectiv pentru un pull request. O cerință care așteaptă un rezultat niciodată produs poate ține îmbinarea blocată, chiar dacă restul condițiilor sunt îndeplinite.

Depozit critic

Ca exemplu de politică mai strictă, păstrează aceeași țintă și cere două aprobări, verificările CI esențiale și respingerea aprobărilor devenite vechi după schimbarea codului. Dacă depozitul folosește CODEOWNERS, poți cere și aprobarea unui proprietar pentru fișierele acoperite. Alege Require branches to be up to date before merging când verificările trebuie să privească o ramură sincronizată cu baza; alte îmbinări în ramura principală pot face necesară reluarea verificărilor.

Pentru un istoric controlat mai strict, poți adăuga Require signed commits și Require linear history. Prima condiție privește semnătura verificată a commiturilor introduse; a doua exclude commiturile de merge de pe ramura vizată. Înainte să ceri istoric liniar, depozitul trebuie să permită îmbinarea prin squash sau rebase. Aceste opțiuni se adaugă cerințelor de recenzie și CI doar dacă fluxul de lucru al proiectului le poate susține.

Alege verificări CI fără nume ambigue

Un nume de job cerut ca verificare obligatorie trebuie să fie distinct între fluxurile de lucru. Ghidul GitHub pentru ramuri protejate avertizează că joburile cu același nume în fluxuri diferite pot produce rezultate ambigue și pot bloca îmbinarea. Verifică numele rezultatului din pull request, nu numai numele fișierului care definește fluxul CI.

Pentru un job dintr-un flux obișnuit, numele verificării este numele jobului; pentru un flux reutilizabil, formatul include atât jobul apelant, cât și pe cel reutilizat. Verificările obligatorii nu disting automat între declanșatoare sau variantele unei matrice. Dacă un flux poate fi omis prin filtre de căi ori de ramuri, rezultatul așteptat poate rămâne Pending și poate bloca îmbinarea. Când accepți rezultatul numai de la o anumită integrare, poți selecta și aplicația GitHub așteptată ca sursă a verificării.

Bypass și Evaluate fără surprize

Bypass list este o excepție acordată unor roluri, echipe sau aplicații, nu o condiție necesară pentru administrator. Nu adăuga rolul de administrator doar pentru comoditate dacă vrei ca și administratorii să respecte aprobările și verificările. Dacă o intervenție excepțională este necesară, acordă dreptul unui actor precis și alege modul potrivit: For pull requests only îi cere să deschidă un pull request, dar îi permite să ocolească protecțiile la îmbinarea acestuia; Always allow permite și ocolirea fără acel traseu.

În GitHub Enterprise Cloud, starea Evaluate arată în Rule Insights ce acțiuni ar fi respectat sau încălcat un ruleset, fără să aplice restricțiile. Este utilă când introduci o politică într-un depozit care are deja contribuții active, însă protecția începe numai după trecerea la Active. Dacă asupra ramurii există și alte reguli active, ele continuă să se aplice în perioada de evaluare; verifică protecția rezultată înainte de a elimina o regulă clasică veche.

Citește și:

• Fila ascunsă din Google Sheets nu protejează datele: verifică accesul
• Inventarul AI Act începe cu instrumentele pe care angajații le folosesc deja
• Google Calendar sau Outlook: agenda simplă pierde la resurse și delegare