GitHub ruleset тавихдаа admin bypass-ыг нээлттэй бүү үлдээ

GitHub repository-ийн үндсэн branch-ийг хамгаалахын тулд түүнд чиглэсэн branch ruleset үүсгэж, pull request, амжилттай status check, баталгаажсан гарын үсэгтэй commit болон force push-ийн хоригийг хамтад нь тохируул. Админыг bypass list-д нэмбэл тэр ruleset-ийн шаардлагыг тойрч болно: GitHub-ийн ruleset тайлбар энэ эрхийг repository admin зэрэг тодорхой үүрэг, баг эсвэл аппад олгож болдгийг заадаг. Өдөр тутмын ажилд онцгой эрх шаардлагагүй бол жагсаалтыг хоосон үлдээ.

Эдгээр дүрэм тус бүр өөр эрсдэлийг хязгаарлана. Pull request нь өөрчлөлтийг merge хийхээс өмнө тусад нь харуулна; status check нь сонгосон автомат шалгалт амжилттай дуусахыг шаардана; signed commit нь гарын үсгийг шалгана; force push-ийн хориг нь branch-ийн түүхийг хүчээр солихоос хамгаална. GitHub-ийн боломжит дүрмийн жагсаалт эдгээр сонголт болон төлөвлөгөөний хамрах хүрээг тайлбарладаг. Pull request шаардах нь өөр хүний зөвшөөрөл авсан гэсэн үг биш: шаардлагатай review-г тусад нь тохируулна.

Үндсэн branch болон bypass эрхийг тохируулах нь

Repository-ийн Settings дотроос Rulesets → Rulesets → New ruleset → New branch ruleset гэсэн замаар ор. GitHub-ийн ruleset үүсгэх заавар Target branches, Bypass list, Branch protections болон enforcement төлөвийг тохируулах дарааллыг өгдөг. Зөвхөн үндсэн branch-ийг хамгаалах бол Target branches хэсэгт default branch-ийг сонго; бүх branch-д зориулсан ерөнхий нэрийн хэв маяг энэ зорилгод хэрэггүй.

1. Ruleset-д зориулалтыг нь таних нэр өг. Target branches хэсэгт default branch-ийг оруулж, өөр branch-ийг санамсаргүй хамруулаагүй эсэхийг хар.
2. Bypass list-д repository admin, organization owner, баг эсвэл GitHub App нэмэгдсэн эсэхийг шалга. Ердийн merge хийхэд тойрох эрх хэрэггүй бол жагсаалтыг хоосон үлдээ.
3. Онцгой ажиллагаанд bypass зайлшгүй хэрэгтэй бол эрх авах этгээдийг тодорхой хязгаарла. For pull requests only сонголт нь шууд push хийхийг зөвшөөрөхгүй, харин тухайн этгээд pull request нээгээд хамгаалалтыг тойрон merge хийх боломжтой хэвээр байдаг.
4. Branch protections хэсэгт шаардлагатай дүрмүүдийг сонгож, бодитоор ажилладаг status check-ийн нэрийг бүртгэ. Эцэст нь ruleset-ийн enforcement төлөв Active байгаа эсэхийг хар; Disabled төлөвт дүрэм хэрэгжихгүй.

Bypass list хоосон байсан ч repository-ийн тохиргоог засах эрхийг тусад нь бодолцоно. Repository admin болон “edit repository rules” эрхтэй custom role нь repository түвшний ruleset-ийг засаж, устгаж чадна. Иймээс merge хийх үеийн bypass эрхийг хязгаарлахын зэрэгцээ дүрмийг өөрчлөх захиргааны эрхийг тохиргоо хариуцдаг хүмүүст хадгалах нь зүйтэй.

Дөрвөн дүрмийн үүрэг ба хоорондын ялгаа

Require a pull request before merging нь үндсэн branch-д орох өөрчлөлтийг pull request-тэй холбодог. Ганцаар ажиллахад ч diff болон шалгалтын үр дүнг merge хийхийн өмнө нэг газраас харах боломжтой. Харин багт хүний хяналт хэрэгтэй бол approving review-ийн шаардлагыг нэм: зөвхөн pull request нээх нөхцөлтэй үед зохиогч өөрөө merge хийх боломжтой.

Require status checks to pass before merging хэсэгт тухайн repository-д ажилладаг build, test эсвэл lint шалгалтыг нэрээр нь сонго. Ажиллахаа больсон check-ийг заавал биелүүлэх нөхцөлд үлдээвэл шинэ pull request merge хүлээнэ. Нэг check-ийн үр дүнг хэн илгээх нь чухал бол хүлээгдэж буй GitHub App-ийг эх үүсвэрээр зааж болно. Үндсэн branch-ийн сүүлийн өөрчлөлттэй нийцүүлэн дахин шалгах strict тохиргоо илүү олон build ажиллуулах шаардлага үүсгэж болох тул багийн ажлын хурдад нийцүүлж сонго.

Require signed commits нь зорилтот branch-д орох commit-ийн гарын үсэг баталгаажсан байхыг шаарддаг. Үүнийг идэвхжүүлэхээс өмнө хөгжүүлэгчид болон commit үүсгэдэг автоматжуулалтын гарын үсгийн тохиргоог бэлд. Pull request доторх гарын үсэггүй commit нь эцсийн squash commit-ийг GitHub гарын үсэгжүүлэх байсан ч merge-ийг саатуулж болно; ийм commit-ийг засахад өөрчлөлтийн branch-ийн түүхийг дахин бичих хэрэг гарч магадгүй.

Block force pushes нь бусдын ажил тулгуурласан commit-ийг үндсэн branch-ийн түүхээс арилгах, эсвэл branch-ийг pull request-ээр зөвшөөрөөгүй commit рүү чиглүүлэх эрсдэлийг хязгаарлана. Үндсэн branch-ийг устгахаас хамгаалах Restrict deletions дүрмийг мөн авч үз. Force push-ийг хориглосон үед админ ч үндсэн branch-ийн нэрийг өөрчлөхөд bypass эрх шаардагдаж болох учраас ийм онцгой ажиллагааг өдөр тутмын merge-ийн эрхтэй хольж болохгүй.

Ажиллах хэлбэрт таарах гурван ruleset загвар

Ганцаар ажиллагч

Нийтийн repository-д GitHub Free, хувийн repository-д GitHub Pro ашиглаж байгаа бол repository түвшний branch ruleset тохируул. Үндсэн branch-д pull request, ажилладаг build эсвэл test check, signed commit болон force push-ийн хориг тавьж, bypass list-ийг хоосон үлдээ. Өөр reviewer байхгүй тул approval шаардах хэрэггүй. Энэ багц нь санамсаргүй шууд push, шалгалт унасан өөрчлөлт, түүхийг хүчээр солих үйлдлийг хязгаарлана; кодыг өөр хүн хянасан гэж үзүүлэхгүй.

Жижиг баг

Байгууллагын нийтийн repository-д GitHub Free for organizations, хувийн repository-д GitHub Team дээр ижил суурь багцыг хэрэглэж болно. Pull request-д нэг зөвшөөрөл шаардаж, шинэ commit diff-ийг өөрчилбөл өмнөх approval-г хүчингүй болгох тохиргоог авч үз. Ингэснээр reviewer-ийн үзсэн хувилбараас хойш өөрчлөгдсөн код хуучин зөвшөөрлөөр merge болох эрсдэл багасна. Баг тогтмол ажиллуулдаг check-үүдийг л шаард; админ бүхэлдээ bypass хийх эрхтэй байвал хүний review болон автомат шалгалтын зорилго алдагдана.

Байгууллага

GitHub Team эсвэл GitHub Enterprise Cloud дээр байгууллагын түвшний ruleset-ээр олон repository-д нийтлэг суурь шаардлага тавьж болно. Кодын эзэн тодорхойлсон файлуудад code owner-ийн review нэмж, тухайн хэсгийг хариуцдаг хүний зөвшөөрөлгүй merge хийхийг хаа. Staging deployment эсвэл code scanning ашигладаг repository-д тэдгээрийн үр дүнг нэмэлт нөхцөл болгож болно. Шалгалт ажилладаггүй repository-д ийм нөхцөлийг хуулж тавих нь merge-ийг саатуулах тул нийтлэг ruleset-ийн хамрах repository болон тус бүрийн ажилладаг шалгалтыг тааруул.

Давхар дүрэм үйлчилж байгааг шалгах нь

Нэг branch-д хэд хэдэн ruleset зэрэг үйлчилж, ижил дүрмийн өөр нөхцөлөөс хамгийн хатуу нь хэрэгжинэ. Хуучин branch protection rule ч ruleset-тэй давхар үйлчилдэг. Тиймээс шинэ ruleset-д review-ийн шаардлагыг сулруулсан ч өөр давхаргад илүү өндөр шаардлага үлдсэн бол merge хүлээгдсээр байна. Байгууллагын ruleset, repository-ийн ruleset болон хуучин branch protection-ийг нэг branch-ийн хувьд хамтад нь хар.

Хадгалсны дараа default branch зөв онилогдсон, төлөв Active, bypass list төлөвлөсөн хэмжээнд байгаа, required check-ийн нэр ажиллаж буй шалгалттай таарч байгааг шалга. Энгийн эрхтэй хэрэглэгчийн pull request-д review болон check-ийн шаардлага харагдах ёстой; шууд push, force push хийх оролдлого хориглогдох ёстой. Онцгой bypass үлдээсэн бол түүнийг хэн, ямар ажиллагаанд ашиглахыг баг дотроо тодорхой болго. For pull requests only эрхтэй этгээд ч хамгаалалтыг тойрон merge хийж чаддаг тул энэ сонголтыг ердийн approval-той адилтгаж болохгүй.

Мөн уншаарай:

• GitHub secret scanning олсон түлхүүрийг устгах нь оройтсон: эхлээд revoke хий
• GitHub Actions-д AWS key хадгалах хэрэггүй: OIDC-г нөхцөлтэй холбо
• DMARC-ийг шууд reject бүү болго: нэг mailto алдаа хамгаалалтыг чимээгүй унтраана