Protected Branches နှင့် Team Workflows

နားလည်ထားရမယ့် အချက်

Branch protection rule တွေက repository ပိုင်ရှင်ကို ဘယ်သူ push လုပ်လုပ်၊ ဘယ်လောက်ကျွမ်းကျင်ကျွမ်းကျင် အရေးကြီးတဲ့ branch (ပုံမှန် main) အတွက် အာမခံချက်တချို့ကို platform level မှာ အတည်ဖြစ်စေနိုင်ပါတယ်။ team ရဲ့ process ကို လူတိုင်း သတိရမယ်လို့ ယုံကြည်မယ့်အစား GitHub က process ကို ကျော်လွှားလာတဲ့ change ကို ငြင်းပယ်နိုင်ပါတယ်။

change တိုင်းဟာ direct push မဟုတ်ဘဲ reviewed pull request မှတစ်ဆင့် ဝင်ရောက်ရမည်။
merge ခွင့်မပြုခင် အနည်းဆုံး review approve တစ်ခု (များသောအားဖြင့် ပိုများ) လိုအပ်သည်။
test suite ဒါမှမဟုတ် linter လို configured status check တွေ အရင် pass ဖြစ်ရမည်။
protected branch ပေါ်မှာ force-push နဲ့ branch ဖျက်ခြင်းကို လုံးဝ ပိတ်ဆို့နိုင်သည်။

ဒီ setting တွေရဲ့ တိကျတဲ့ စကားလုံးနဲ့ layout ဟာ GitHub က interface ကို update လုပ်တာနဲ့အမျှ ကြာလာတာနဲ့ ပြောင်းလဲသွားနိုင်လို့ ဒီသင်ခန်းစာမှာ menu လမ်းကြောင်းအတိအကျထက် အခြေခံ concept တွေကို ဖော်ပြထားပါတယ်။

repository တစ်ခုတည်းထက် ကျော်ပြီး GitHub Organizations က company တစ်ခုကို repository များစွာနဲ့ လူများစွာကို အတူတကွ manage လုပ်ခွင့်ပေးပါတယ် — team တွေက လူတွေကို စုစည်းပေးပြီး read၊ write၊ admin လို permission တွေကို လူတစ်ဦးချင်းစီ configure မလုပ်ဘဲ team တစ်ခုကို repository တစ်ခုအပေါ် ပေးအပ်ပါတယ်။

ဆက်စပ်ပြီး engineering org တိုင်း ကြီးထွားလာတာနဲ့အမျှ ရင်ဆိုင်ရမယ့် ပွင့်လင်းတဲ့ မေးခွန်းက monorepo vs multi-repo ပါ။ monorepo တစ်ခုတည်းက project ကူးပြီး change တွေကို atomic ဖြစ်စေပြီး shared code ကို ပြန်သုံးရလွယ်စေပေမယ့် history နဲ့ build tooling က ခန့်လာနိုင်ပါတယ်။ project တစ်ခုချင်းစီ repo ခွဲထားရင် deploy pipeline သီးသန့်နဲ့ team ownership boundary ပိုရှင်းလင်းစေပေမယ့် repo တစ်ခုထက်ပိုကျော်တဲ့ change ကို ညှိရမှာဖြစ်ပါတယ်။ ဘယ်ဟာမှ အမြဲပိုကောင်းတယ်လို့ မဆိုနိုင်ပါဘူး။

text

PROTECTED MAIN: ONLY REVIEWED, PASSING PRS GET IN
-------------------------------------------------
   direct push  ----X  BLOCKED (branch protection rule)
                          |
   feature branch --> pull request --> review required
                          |                 |
                          |          checks must pass
                          |                 |
                          +------> merge allowed -----> main

လက်တွေ့ scenario နဲ့ ချိတ်ကြည့်မယ်

ဒီမှာ ပြသစရာ terminal command မရှိပါဘူး — branch protection ဟာ GitHub website ပေါ်က repository Settings, Branches အောက်က configuration အပြည့်အစုံဖြစ်ပြီး ရိုးသားစွာ စမ်းသပ်နိုင်မယ့် local run လုပ်စရာ မရှိပါဘူး။ အောက်ကဖော်ပြချက်များသည် capture လုပ်ထားသော transcript မဟုတ်ဘဲ တကယ်ဖြစ်ပျက်တဲ့အရာကို တိကျစွာ ဖော်ပြထားခြင်းသာ ဖြစ်ပါသည်။

Direct push ကို ငြင်းပယ်ခြင်း

pull-request review လိုအပ်တဲ့အခါ ဘယ်သူ့ machine ကမဆို (setting များစုမှာ admin ပါအပါအဝင်) git push origin main direct လုပ်ရင် object တွေ လက်ခံခင်ကတည်းက GitHub server က branch protected ဖြစ်ပြီး pull request လိုအပ်ကြောင်း error နဲ့ ငြင်းပယ်ပါတယ်။

Commit တွေ ဆုံးရှုံးမသွားပါ

commit တွေ ဆုံးရှုံးသွားတာ မဟုတ်ပါဘူး — main ကို ရောက်မသွားတာသာဖြစ်ပါတယ်၊ ပုံမှန်အားဖြင့် branch အသစ်တစ်ခုပေါ် push လုပ်ပြီး pull request ပုံမှန်ဖွင့်ရပါတယ်။

Force-push ကိုလည်း ပိတ်ဆို့ထားသည်

force-push protection ဖွင့်ထားရင် git push --force origin main ကိုလည်း ဘယ်သူ push လုပ်လုပ် အလားတူ ငြင်းပယ်ပြီး shared history အဆိုးဆုံး ပျက်စီးနိုင်တဲ့ လမ်းကြောင်းကို ပိတ်ဆို့ပေးပါတယ်။

Status check တွေက Merge ခလုတ်ကို ထိန်းချုပ်သည်

required review approval ရရှိပြီးသားဖြစ်နေတောင် required check တိုင်း success မဖြစ်ခင် GitHub က pull request ရဲ့ merge ခလုတ်ကို disable ထားပါတယ်။

Branch protection ဟာ platform level မှာ reviewed pull request၊ required status check၊ force-push ပိတ်ဆို့ခြင်းတို့ကို အရေးကြီးတဲ့ branch တွေအပေါ် အတည်ဖြစ်စေပါတယ်။
GitHub Organizations က လူတွေကို team အဖြစ် စုစည်းပြီး repository permission တွေကို လူတစ်ဦးချင်းစီအစား team level မှာ ပေးအပ်ပါတယ်။
Monorepo နဲ့ multi-repo နှစ်ခုစလုံးက atomic cross-project change / shared code ကို independent deploy / team boundary ရှင်းလင်းမှုနဲ့ လဲလှယ်ကြပါတယ် — ဘယ်ဟာမှ အမြဲပိုကောင်းတယ်လို့ မဆိုနိုင်ပါဘူး။

အတူတူ စမ်းရေးကြည့်မယ်

bash

# Illustrative only -- branch protection is GitHub-side configuration,
# not reproducible as a local git command. Not executed for this lesson.

git push origin main
# rejected: GitHub blocks the push because main requires a pull request

git push --force origin main
# rejected: force-pushes are blocked on a protected branch

Terminal မှာ run လို့မရပါ

ဒီအပိုင်းက GitHub ရဲ့ web platform behavior ကို ရှင်းပြထားတာဖြစ်လို့ terminal မှာ တိုက်ရိုက် run လို့မရပါ (PR/Issue ဖန်တီးခြင်း, branch protection setting, Actions run trigger စတာတွေက GitHub server ပေါ်မှာသာ ဖြစ်ပျက်ပါတယ်)။ ကိုယ်ပိုင် GitHub repository တစ်ခုမှာ ကိုယ်တိုင် လိုက်လုပ်ကြည့်ပါ။

You should see

ဒီသင်ခန်းစာရဲ့ runnable field ဟာ false ဖြစ်ပါတယ် — branch protection အတွက် execute လုပ်နိုင်တဲ့ local git command equivalent မရှိလို့ အထက်က ဘာမှ run မထားပါဘူး။ ဖော်ပြထားတဲ့ behavior ဟာ GitHub ရဲ့ မှတ်တမ်းတင်ထားတဲ့ branch protection rule တွေနဲ့ ကိုက်ညီပါတယ် — protected branch ကို direct ဒါမှမဟုတ် force push လုပ်ရင် server-side မှာ ငြင်းပယ်ခံရပြီး required review နဲ့ status check ပြည့်စုံမှသာ merge ခွင့်ပြုပါတယ်။ error စာသားကို GitHub screen တစ်ခုခုကနေ တိုက်ရိုက် ကိုးကားထားတဲ့ transcript အဖြစ်မဟုတ်ဘဲ သဘောသဘာဝ တိကျမှုအဖြစ်သာ ယူပါ — GitHub က UI update လုပ်တာနဲ့အမျှ တိကျတဲ့ စကားလုံးက ပြောင်းလဲနိုင်ပါတယ်။

၅ မိနစ် စမ်းကြည့်

ကိုယ်ထိန်းချုပ်တဲ့ GitHub repository အစစ်တစ်ခုမှာ main ပေါ် pull request နဲ့ review အနည်းဆုံးတစ်ခု လိုအပ်တဲ့ branch protection ဖွင့်ပါ။ main ကို direct push လုပ်ကြည့်ပြီး GitHub ပေးတဲ့ ငြင်းပယ်ချက် message အတိအကျကို ဖတ်ကြည့်ပါ။ ပြီးရင် partner တစ်ယောက်နဲ့ ဆွေးနွေးပါ — သင့် team လက်ရှိအတွက် monorepo ဒါမှမဟုတ် multi-repo ကွဲထုတ်ခြင်း ဘယ်ဟာက ပိုအကျိုးရှိမလဲ၊ ဘာကြောင့်လဲ။

သတိလေးတစ်ချက်

admin ကတော့ branch protection ကို default အနေနဲ့ ကျော်လွှားနိုင်တယ်လို့ ယူဆခြင်း — configuration ကောင်းကောင်းအများစုက admin ကိုပါ rule ကျင့်သုံးလို့ မရှိနိုင်တဲ့ exception ကို အားကိုးရင် လုံခြုံမှု အယူအဆမှားနေတာပါ။

team ရဲ့ တကယ့် coordination လိုအပ်ချက်နဲ့ deploy independence လိုအပ်ချက်အစား လက်ရှိ trend ကို အခြေခံပြီး monorepo ဒါမှမဟုတ် multi-repo ရွေးချယ်ခြင်း။

GitHub Docs - About protected branches — Git & GitHub