ကျွန်တော်တို့ developer တွေဘဝမှာ Git ဆိုတာမရှိမဖြစ်ပဲ။ ဘယ် dev မဆို တစ်ချိန်ချိန်မှာတော့ Git ကိုသုံးကိုသုံးရမှာပဲ။ Team တစ်ခုနဲ့တစ်ခုကလည်း အသုံးပြုတဲ့ Git structure က မတူကြဘူး။ အခုလက်ရှိမှာတော့ အသုံးများတဲ့နည်းနှစ်ခုက Git Flow နဲ့ Trunk-Based development ဆိုပြီးရှိတယ်။ ဒီနှစ်ခုကိုပဲအခြေခံပြီး Team မှာ အသုံးပြုပုံက နည်းနည်းလေးကွဲသွားတာမျိုးတော့ရှိတယ်။
Git Flow
Git Flow ကတော့ Vincent Driessen ရဲ့ Model ကို အခြေခံထားတယ်။ သူ့မှာmain branch ဆိုပြီး production ကိုသွားဖို့ အဆင်သင့်ဖြစ်နေတဲ့ branch တစ်ခုရှိတယ်။ ပြီးရင် main ကနေခွဲထွက်ပြီး development ရဲ့ နောက်ဆုံး အခြေအနေကို သတ်မှတ်ပေးတဲ့ develop branch ရှိတယ်။ ကျွန်တော်တို့က feature တွေရေးရင် develop ကနေခွဲထွက်လာတဲ့ feature branch တစ်ခုသတ်မှတ်ပြီးရေးတယ်။ အဲ့ feature ပြီးသွားပြီဆိုတော့မှ develop ကို ပြန် merge တယ်။ Release လုပ်တော့မယ့်ဆိုရင် develop ကနေပြီး release branch တစ်ခုခွဲထွက်လိုက်တယ်။ အဲမှာ test မယ် ပြင်စရာရှိတာပြင်မယ်။ ပြီးရင် master ကို merge ပြီး release လုပ်မယ်။
ဒါက Team မှာ Structure ကျကျ လုပ်ချင်တဲ့အချိန်မှာ တော်တော်အဆင်ပြေတယ်။ Senior Developer တွေကနေ Merge request (MR) တွေကို ကြည့်ပေးမယ်၊ လက်ခံလို့ရတဲ့ အခြေအနေတစ်ခုရောက်ပြီဆို merge လုပ်ပေးတယ်။ ဒီတော့ Code quality ကိုထိန်းလို့ရတယ်။ သူတစ်ပေါက် ကိုယ်တစ်ပေါက် ရေးတာမျိုးဖြစ်မနေဘူး။ ဆိုးတာကတော့ MR ဆိုတဲ့ သဘောအတိုင်းပဲ ကြာတယ်။ မှားလိုက်ပြင်လိုက်နဲ့ ကြာတတ်တယ်။ နောက်တစ်ခုက Feature တွေက "Long-lived" branch လို့ခေါ်တဲ့ သက်ဆိုးရှည်တဲ့ အချိန်ဖြစ်သွားတဲ့အခါ master/develop ကို ပြန် ပေါင်းတဲ့အခါကျ တော်တော်အချိန်ပေးပြီး Merge conflict ပြန်ပြင်ရတဲ့အရာမျိုးတွေ ကြုံရတတ်တယ်။
Trunk Based Development
Trunk based development ဆိုတာကတော့ Developer အကုန်လုံးက တတ်နိုင်သလောက် main ပေါ်မှာ ဝိုင်းရေးကြတယ်။ commit ကိုသေးနိုင်သလောက်သေးပြီး commit တစ်ခုပြီးတာနဲ့ main ပေါ်ကို တန်းတင်တယ်။ Branch ခွဲရမယ်ဆိုလည်း သက်တမ်းကို တိုနိုင်သလောက် တိုအောင်ထားတယ်။ သူ့မှာ release branch မရှိဘူး။ CI/CD Pipeline ကနေ main ပေါ်ရောက်သမျှ တောက်လျှောက် build ထုတ်ပေးနေတယ်။
Trunk ကဘာကောင်းလဲဆိုတော့ Commit သေးသေးလေးတွေလုပ်တဲ့အကျင့်ရသွားတယ်။ ဥပမာ listing ပြရမဲ့နေရာကို API နဲ့ချိတ်တဲ့ အပိုင်းက တစ်ခု၊ UI ကတစ်ခု၊ refactor ပြန်လုပ်တာက တစ်ခု အစရှိသဖြင့် သေးသေးလေးတွေ commit လုပ်တတ်လာတယ်။ Commit တွေကသေးတော့ main ပေါ်ပြန်တင်ရတာလည်း တော်တော်လွယ်တယ်။ Merge conflict ဆိုတာ မရှိသလောက်ကို နည်းတယ်။
Trunk မှာက merge request review လုပ်တဲ့အခါ အကြာကြီး အချိန်ယူပြီး မလုပ်ရအောင် automated check တွေတတ်နိုင်သလောက်ထားပေးရတယ်။ Automation မှာမှ Unit Test, Lint check, Test Coverage report, E2E Test တွေအကုန်ရှိတဲ့အခါကျ push လိုက်တာနဲ့ တစ်ခုခုမှားနေရင် ချက်ချင်းတန်းမြင်ရတယ် Reviewer အနေနဲ့လည်းဒါတွေမှန်နေပြီဆိုရင် စိတ်ချလို့ရသွားတယ်။ (Git flow မှာလည်း ဒါတွေရှိပေမဲ့ merge conflict ရှင်းတာက လူကိုယ်တိုင်လုပ်ရတော့ continue flow အနှစ်သာရ ပျောက်သွားတယ်) နောက်ကောင်းတာက commit/MR သေးသေးလေးတွေဖြစ်တဲ့အတွက် reviewer အနေနဲ့ ဖတ်ရတာ ပိုလွယ်တယ်။ Git flow မှာလို Feature ကြီးတစ်ခုလုံးကို ဖတ်ရတဲ့အခါကျတော့ reviewer အနေနဲ့ ဘာရေးထားလဲနားလည်ဖို့ တော်တော်စဥ်းစားရတယ်။ ကျွန်တော်အခုလုပ်နေတဲ့ အလုပ်မှာတော့ review အဆင့်ဆိုတာ မရှိသလောက် နည်းတယ်။ Pair Programming လုပ်တဲ့အခါကျ တစ်ယောက်ကရေးနေရင် နောက်တစ်ယောက်က တစ်ခါတည်း စစ်ပေးသလိုဖြစ်နေတော့ main ေပါ်ကိုတန်းတင်ကြတယ်။
ဒီတော့မေးစရာက commit လေးတွေခွဲပြီး main ပေါ်တင်တဲ့အခါကျ feature တွေမပြီးသေးတဲ့ ဟာတွေ၊ ဥပမာ UI တစ်ဝက်တစ်ပျက်ကြီး user လက်ထဲ ရောက်မသွားနိုင်ဘူးလားပေါ့။ ဒီလိုမရောက်အောင် ကျွန်တော်တို့က feature flag လေးတွေနဲ့ထိန်းတယ်။ Backend သို့မဟုတ် remote config လိုမျိုးမှာ feature flag လေးတွေကို true/false toggle လေးတွေ လုပ်လို့ရအောင် လုပ်ထားတယ်။ Release လုပ်ပြီးလို့ ဒီ feature က ပြဿနာတတ်နေတယ် ဆိုရင်လည်း flag ပိတ်လိုက်ပြီး အရင် version အတိုင်းပြန်ဖြစ်သွားအောင် လုပ်လို့ရသွားတယ်။
Trunk က ဘယ်လိုနဲ့ကိုက်လဲဆိုတောင် Agile Team တွေနဲ့ကိုက်တယ်။ CI/CD နာမည်အတိုင်း တကယ့်ကို Continuously ဖြစ်နေတယ်။ မြန်မြန် release လုပ်ပြီး မြန်မြန် ရလဒ်ကို သိရတယ်။ ဒါပေမဲ့ Trunk သွားမယ်ဆိုရင်တော့ CI/CD တွေ, Testing pipeline တွေ Feature flag, phased release လိုမျိုး Tooling support တော့လိုမယ်။ နောက်တစ်ခုက ကိုယ့် Team/Culture က လုပ်ပိုင်ခွင့် Autonomy ပေးလို့ရသလို တာဝန်ယူတတ်တဲ့စိတ်ရှိ တဲ့ အခြေအနေတစ်ခုရှိရမယ်။ ဒါမှ blame game တွေနဲ့ အချိန်ကုန်မနေမှာဖြစ်တယ်။