GitHub-ի main-ը փակեք նաև admin-ից․ լռելյայն շրջանցումը մնում է

GitHub-ի main ճյուղը ուղիղ push-ից և չստուգված միավորումից պաշտպանելու համար պահանջեք pull request, հաստատում ու պարտադիր CI ստուգումներ, ապա միացրեք «Do not allow bypassing the above settings»։ GitHub-ի պաշտպանված ճյուղերի կանոններով՝ force push-ն ու ջնջումը լռելյայն արգելված են, բայց admin իրավասությամբ օգտատերերն ու շրջանցման հատուկ իրավունք ունեցող դերերը կարող են շրջանցել կանոնի սահմանափակումները, եթե այն նրանց վրա էլ չտարածեք։

Այս կարգավորումները տարբեր արգելքներ են դնում։ Pull request-ի պահանջը փակում է սովորական ուղիղ push-ի ճանապարհը, հաստատումը պահանջում է վերանայող, իսկ պարտադիր ստուգումները կանգնեցնում են միավորումը մինչև CI-ի ընդունելի արդյունքը։ Admin-ի շրջանցումը փակող նշումը նույն ընթացակարգը տարածում է նաև պահոցի կառավարիչների վրա։

Ստեղծեք main-ի նվազագույն կանոնը

Պահոցի Settings → Branches → Branch protection rules բաժնում ընտրեք Add classic branch protection rule։ GitHub-ի կանոն ստեղծելու հրահանգում «Branch name pattern» դաշտը նախատեսված է պաշտպանվող ճյուղի անվան համար. այստեղ գրեք main։ Եթե արդեն կան main-ին համապատասխանող այլ դասական կանոններ, հաշվի առեք, որ միաժամանակ գործում է դրանցից միայն մեկը. ճյուղի ճշգրիտ անունով կանոնը գերակայում է ընդհանուր օրինաչափությամբ կանոնին։

1. Միացրեք «Require a pull request before merging»։ Եթե թիմում կա առանձին վերանայող, դրա ներսում միացրեք «Require approvals» և ընտրեք մեկ հաստատում։
2. Միացրեք «Require status checks to pass before merging» և ընտրեք այն CI ստուգումները, որոնք արդեն արդյունք են հաղորդում դեպի main ուղղված pull request-ների համար։
3. Միացրեք «Do not allow bypassing the above settings»։ «Allow specified actors to bypass required pull requests» տարբերակում բացառություն մի ավելացրեք, եթե թիմը գիտակցաբար չի նախատեսել այդ իրավունքը։
4. «Allow force pushes» և «Allow deletions» տարբերակները թողեք անջատված, ապա պահպանեք կանոնը։

Սա փոքր թիմի նվազագույն պրոֆիլն է, երբ CI-ն արդեն աշխատում է և կա փոփոխությունը վերանայող մարդ։ Եթե դեռ չկա համապատասխան CI ստուգում, նախ գործարկեք այն pull request-ների համար. չհաղորդվող արդյունքը պարտադիր ընտրելը կարող է փակել նաև պատշաճ վերանայված փոփոխության միավորումը։ Միայնակ աշխատող պահոցում ուրիշի հաստատումը պահանջելը գործնական փակուղի կստեղծի, ուստի հաստատումների պահանջը հարմարեցրեք թիմի կազմին։

Ի՞նչ է փակում admin-ի շրջանցման նշումը

«Do not allow bypassing the above settings» կարգավորումը կանոնի սահմանափակումները տարածում է admin իրավասությամբ օգտատերերի և «bypass branch protections» իրավունքով դերերի վրա։ Առանց դրա սովորական մասնակիցը պետք է անցնի pull request-ի և ընտրված ստուգումների միջով, մինչդեռ կառավարիչը կարող է շրջանցել դրանք։ Հետևաբար միայն force push-ի անջատված նշումից չի հետևում, որ main-ը նույն կերպ պաշտպանված է բոլորի համար։

«Restrict who can push to matching branches» կարգավորումն այլ նպատակ ունի. այն սահմանում է, թե ով կարող է push անել պաշտպանվող ճյուղին, բայց push-ի թույլտվություն ունեցողները միևնույն է պետք է կատարեն pull request-ի և ստուգումների պահանջները, եթե դրանք միացված են։ Admin իրավասությամբ մարդը կարող է նաև փոխել հենց պաշտպանության կանոնը։ Այդ իրավասությունը սահմանափակեք կանոնը կառավարող մարդկանցով, իսկ սովորական փոփոխությունների համար պահեք նույն պարտադիր ընթացակարգը։

Ընտրեք CI ստուգումները և strict ռեժիմը

Պարտադիր դարձրեք միայն այն ստուգումները, որոնց արդյունքն անհրաժեշտ է միավորումը թույլ տալու համար՝ օրինակ հավաքումը կամ նախագծի թեստերը։ Ընտրելիս ուշադրություն դարձրեք ստուգումների անուններին. տարբեր workflow-ներում նույնանուն job-երը կարող են երկիմաստ արդյունք առաջացնել և արգելակել pull request-ը։ GitHub-ը պարտադիր ստուգման համար ընդունում է successful, skipped կամ neutral վիճակները. դեռ սպասվող կամ ձախողված արդյունքով միավորումը չի անցնի։

«Require branches to be up to date before merging» նշումը միացնում է strict ռեժիմը։ Դրանով pull request-ի ճյուղը միավորումից առաջ պետք է համընթաց լինի main-ի վերջին վիճակին։ Եթե մեկ ուրիշ փոփոխություն արդեն մտել է main, սպասող ճյուղը կարող է թարմացման և CI-ի նոր գործարկման կարիք ունենալ։ Սա օգտակար է, երբ առանձին անցած փոփոխությունները կարող են անհամատեղելի լինել միասին, բայց հաճախակի միավորումների դեպքում ավելացնում է սպասումն ու կրկնվող ստուգումները։

Եթե այդ նշումը անջատեք, ընտրված ստուգումները շարունակում են պարտադիր մնալ, սակայն pull request-ի ճյուղը պետք չէ թարմացնել main-ի յուրաքանչյուր նոր փոփոխությունից հետո։ Այդպես CI-ն ավելի քիչ անգամ կաշխատի, փոխարենը կմնա հավանականություն, որ նախկինում անցած ստուգումը չի ներառել main-ի միջանկյալ փոփոխությունը։ Փոքր թիմում, որտեղ միավորումները հազվադեպ են հատվում, սա կարող է լինել ընդունելի փոխզիջում. հաճախակի հատումների դեպքում strict ռեժիմն ավելի կարևոր է դառնում։

Երբ պահանջել ստորագրված commit-ներ

«Require signed commits» պահանջը միացրեք, երբ մշակողներն ու փոփոխություն կատարող բոտերը կարողանում են ստեղծել GitHub-ի կողմից վավերացված ստորագրությամբ commit-ներ։ Ստորագրությունը վերաբերում է commit-ին. այն չի փոխարինում ո՛չ pull request-ի վերանայմանը, ո՛չ CI-ի ստուգմանը։ Պահանջը վաղ միացնելու դեպքում արդեն բաց pull request-ներում եղած չստորագրված commit-ները կարող են կանգնեցնել միավորումը։

Նույնը վերաբերում է squash merge-ին. GitHub-ը միավորումից առաջ ստուգում է pull request-ով ներկայացված commit-ները, ուստի չստորագրված commit-ը կարող է խանգարել, նույնիսկ եթե վերջնական squash commit-ը ստորագրվելու է։ Նման pull request-ը շտկելու համար պետք է վերագրել և ստորագրել չստորագրված commit-ները, ապա թարմացնել փոփոխության ճյուղը։ Եթե միացված է նաև նոր commit-ներից հետո հին հաստատումները չեղարկելու պահանջը, վերագրումից հետո կարող է անհրաժեշտ լինել նոր հաստատում։

Երբ ավելացնել merge queue

Երբ մի քանի pull request հաճախ են միաժամանակ սպասում main-ի վրա, merge queue-ն ստուգում է հերթում եղած փոփոխությունը main-ի վերջին վիճակի և իրենից առաջ կանգնած փոփոխությունների հետ միասին։ Հեղինակը ստիպված չէ ամեն անգամ ինքնուրույն թարմացնել իր ճյուղը։ GitHub-ի merge queue-ի հրահանգով՝ այն հասանելի է կազմակերպության հանրային պահոցներում, իսկ մասնավոր պահոցների համար պահանջվում է GitHub Enterprise Cloud։

Հերթն ակտիվացնելու համար main-ի պաշտպանության կանոնում ընտրեք «Require merge queue»։ Եթե պարտադիր ստուգումներն աշխատում են GitHub Actions-ով, workflow-ի pull_request գործարկչի կողքին ավելացրեք merge_group գործարկիչը։ Հերթը ստեղծում է ժամանակավոր միավորման խումբ, և առանց այդ խմբի համար հաղորդված պարտադիր CI արդյունքի փոփոխությունը չի միավորվի։ Արտաքին CI ծառայության դեպքում ևս պետք է կարգավորել ստուգումները հերթի ստեղծած ժամանակավոր ճյուղերի համար։

Merge queue-ն չի միացվում branch protection-ի այն կանոնին, որի ճյուղի անվան օրինաչափությունում աստղանիշ կա. main-ի համար օգտագործեք ճշգրիտ անունը։ Եթե խմբի պարտադիր ստուգումը ձախողվում է կամ փոփոխությունը հակասում է main-ին, հերթը հեռացնում է խնդրահարույց pull request-ը և շարունակում մյուսների ստուգումը։ Հազվադեպ համընկնող pull request-ներով փոքր թիմի համար հերթի լրացուցիչ CI կարգավորումն ու սպասումը կարող են ավելորդ լինել. այն ավելացրեք, երբ միավորումների հոսքն արդեն արդարացնում է այդ բարդությունը։

Կարդացեք նաև:

• Գաղտնի տվյալը մի՛ տեղադրեք ԱԲ prompt-ում․ պաշտպանեք նաև հիշողությունն ու մատյանները
• GitHub Actions-ի ամպային բանալիները փոխարինեք մեկ job-ի OIDC token-ով
• Prompt injection-ը filter-ով չի փակվում․ պաշտպանեք նաև գործակալի հիշողությունը