ကျနော်နှင့် GitFlow
ရေးမယ်ရေးမယ်နဲ့ တော်တော်နဲ့ မရေးဖြစ်ဘဲ အခုမှပဲ Git Flow အကြောင်း လေးရေးပေးလိုက်ပါတယ်။ ညီအစ်ကိုတို့အတွက် တစ်ထောင့်တစ်နေရာက အသုံးဝင်မယ်ဆို ရေးပေးရကျိုး နပ်ပါတယ်။
ရှေ့ဦးစွာ စကားပလင်ခံလိုတာက ကိုယ်လုပ်ငန်းခွင်က သတ်မှတ်ထားတဲ့ flow တစ်ခုနဲ့တစ်ခု မတူတဲ့အတွက် လိုအပ်ချက်ပေါ်မူတည်ပြီး ကွဲပြားသွားနိုင်တာ သတိချပ်စေလိုပါတယ်။
ကျနော့်တို့ လုပ်ငန်းခွင်ရဲ့ policy အရ master branch မှာ ဘယ်သောအခါမှ တိုက်ရိုက် push လုပ်ခွင့်မရှိပါဘူး။ လက်ရှိမှာ master နဲ့ develop ရယ် အကြမ်းဖျဥ်း ရှိပါတယ်။ သက်ဆိုင်ရာ developer တိုင်းက feature အသစ်တွေ bug fix တွေဆို develop ကနေ branch အသစ်ယူရပါတယ်။ ပြီးမှ ကိုယ့် checkout လုပ်ထားတဲ့ branch ကနေပြီး Develop ကို ပြန် Merge လုပ်ရတယ်။ ပြီးတော့မှ master ကို ပြန်ပြီး Merge လုပ်ကြပါတယ်။
ဒါတော်တော်များများနည်းလည်ထားတဲ့ flow ပါ။ ဒီ Flow တစ်ခုလုံးရဲ့ အားနည်းချက်ကို ပြပါဆိုရင် အောက်က ပုံကို ကြည့်ပါ။ ဒါ Flow အနည်းငယ် ချိန်းထားပြီးသားပုံပါ။ ကျနော့်မှာ ပုံအဟောင်းမရှိတော့လို့ပါ။ တကယ်က အဲ့ထက်ပိုရှုပ်ပါတယ်။ အကယ်၍များ ကျနော် အဲ့ထဲက commit လေးတစ်ခုပဲ release လုပ်ချင်တယ်ဆို သေအောင် တိုင်ပက်ပါပြီ။ rebase လုပ်မလား cherry-pick လုပ်မလား စတဲ့ မေးခွန်းတွေ လာပါလိမ့်မယ်။ rebase နဲ့ cherry-pick အကြောင်းနောက်မှ ရှင်းပေးပါမယ်။
အခု Flow အသစ်လေးကို တစ်ချက် ကြည့်ကြည့်ရအောင်
ကျနော့်တို့မှာ Developer ပေါင်းများစွာက branch အသစ်တွေခွဲ Pull request တွေလုပ်နဲ့ ဒီလို one line straight ဖြစ်အောင် ဘယ်လိုလုပ်လဲ စဥ်းစားစရာပါ။ ဒါပေမဲ့ တကယ်တော့ ဒါဟာ standard တစ်ခုကို အခြေခံထားရင် လွယ်လွယ်လေးပါ။
ဘယ်လို standard လဲ…..?
master or develop branch ကိုဘယ်တော့မှ တိုက်ရိုက် push မလုပ်တော့ပါဘူး။ develop branch ကိုတော့ Circle CI ဒါမှမဟုတ် Travis CI စတဲ့ minification process တွေ or CI/CD Process တွေက တစ်ခုခုလိုအပ်ရင် push လုပ်ခွင့်ပေးထားပါတယ်။ ဒါပေမဲ့ enduser က push လုပ်လို့မရတော့ပါဘူး။ လူတိုင်း push မလုပ်တဲ့အတွက် remote origin သည် အားလုံးအတွက် အတူတူပါပဲ။
Developer က branch တစ်ခု develop အောက်က create လုပ်ချင်တာနဲ့ အရင်ဆုံး
git fetch origin နဲ့ remote host က update ယူထားပါတယ်။ ပြီးမှ git pull --rebase လုပ်ထားလိုက်ပါတယ်။ ပြီးတာနဲ့ ကိုယ် branch တစ်ခုကို Develop ကနေစခွဲထွက်ပါတယ်။
ကိုယ့်အလုပ်တွေပြီးတာနဲ့ Commit လုပ်။ ပြီးတာနဲ့ ကိုယ့်ရဲ့ branch ကနေပြီး develop branch ကို pull request တင်ပြီး သက်ဆိုင်ရာ supervisor ကို review လုပ်ဖို့အတွက် assign လုပ်ပါတယ်။ ကိုယ့် supervisor က review လုပ်ပြီး approve ဖြစ်ရင် develop ကို merge လုပ်ပါတယ်။ ပြီးတာနဲ့ ကိုယ့်ရဲ့ remote branch ကို ဖျက်ပစ်ပါတယ်။
release လုပ်တော့မယ်ဆို master branch ကနေပြီး release branch ခွဲထုတ်ပြီးတာနဲ့ release branch ထဲက develop က release လုပ်ချင်တဲ့ Commit တွေကို cherry-pick အနေနဲ့ ယူပါတယ်။ ပြီးမှာ release branch ကို push လုပ်ပြီး master နဲ့ merge လုပ်ပြီး release လုပ်ပါတယ်။
cherry-pick ဘာလဲဘယ်လဲ။
cherry သီးခူးတာပါ :D ..တကယ်ပြောတာ…ဆိုလိုတာက ကိုယ်လိုချင်တဲ့ commit လေးပဲ ယူပြီး target branch ထဲထည့်တာ။ အောက်ကပုံလေးကိုကြည့်ပါ။ ကိုယ်က E commit ကို release လုပ်တဲ့ထဲ မထည့်ချင်ဘူး။ C, F ရယ် က release လုပ်လို့ ok ပြီ… နောက် D က လည်း release လုပ်လို့ရပြီဆို D ကို cherry-pick လုပ်ပြီး release branch ထဲ ထည့်လိုက်တာပါ။
တစ်ခုသတိထားစရာ ရှိပါတယ်။ ဆိုပါဆို ကိုယ့်ရဲ့ D branch မှာ ပထမ commit က initial commit ဖြစ်ပြီး ပြီးမှ typo error /logic enhancement ရှိလို့ ပြန်ပြင်ထားရင် commit ၂ ခု ရှိနေပါပြီး။ ဒါဆို ဘယ်လိုလုပ်မလဲဆိုတာ ပေါ်လာပါပြီ။ Cherry-pick လုပ်ရင် အရင်ဆုံး commit ကို ပထမဆုံး cherry-pick (bottom to up)လုပ်ပြီးမှ နောက်ဆုံ commit ကို cherry pick ထပ်လုပ်ရပါတယ်။ ဒါမှ updated အကုန် ပါနေမှာပါ။ ကိုယ်က တစ်ခုပဲ လုပ်လိုက်ရင် code တွေ ကျန်ခဲ့ပြီး error တွေ တက်မှာပါ။ နောက်တစ်နည်းက squash ပါ။
squash ဘာလဲဘယ်လဲ။
ဆိုတာက commit 2 ခု branch တစ်ခုထဲမှာ ရှိနေရင် တစ်ခုပဲ ဖြစ်အောင် လုပ်ထားတာပါ။ ဥပမာ ကျနော် ပထမ commit နှစ်ခုက CI/CD process မှာ failed ဖြစ်တဲ့အတွက် fixed လုပ်ပြီး နောက်ဆုံး commit က sucess ဖြစ်လို့ ready to merge to master ပါ (။ ဒါပေမဲ့ ကျနော့်မှာ commit message ကသုံခုတောင်။ in case ကြောင့် သူတို့ rebase လုပ်ပြီး cherry pick နဲ့ release လုပ်ရင် sorting order တွေ straight line မဟုတ်ရင် ကြည့်ရခက်ပါတယ်။ ဒါကြောင် squash နဲ့ သုံးခုကနေ တစ်ခု လုပ်ပြီး force push နဲ့ history ကို override လုပ်လိုက်တာပါ။
စာလည်း ရှည်ပြီမို့ rebase, drop commit, revert commit စတာတွေကို နောက်အပတ်တွေမှာ ရေးပေးသွားပါမယ်။
Stay tune
