Git အခြေခံ

အခြေခံဆိုမှ တကယ့်အခြေခံပါ။ Absolute Beginner တွေအတွက် ရည်ရွယ်ပြီး ရေးပါတယ်။ ဥပမာမပါဘဲ ဒီတိုင်းပြောပြတာထက်စာရင် Case Study လေးတစ်ခုခုနဲ့ တွဲပြီး ပြေပြရင် ပိုအဆင်ကောင်းမယ် ထင်ပါတယ်။ ဒါကြောင့် Reborn ဆိုတဲ့ CMS တစ်ခု Develop လုပ်ခဲ့တုန်းက အကြောင်းလေးနဲ့ တွဲပြီး ပြောပြချင်ပါတယ်။ (စကားချပ် - Reborn CMS ကတော့ အကြောင်းအမျိုးမျိုးကြောင့် Beta Version မှာတင် သေသွားပါတယ်။ စိတ်ပါလို့ Contribute လုပ်ချင်တယ်ဆိုရင်တော့ ဒီနေရာမှာ လုပ်လို့ရပါတယ်)

Reborn ဆိုတဲ့ Content Management System ကို စရေးတုန်းက Modular Structure နဲ့ Module တွေခွဲပြီး ၅ ယောက်၊ ၆ ယောက် (မသေချာတော့) ဝိုင်းရေးခဲ့ကြပါတယ်။ Core or Foundation ကတော့ ကျွန်တော်တို့ရဲ့ Lead Developer က ရေးတယ်။ ကျန်တဲ့သူတွေက ကိုယ်တာဝန်ယူထားတဲ့ Module ကို ကိုယ့်ဟာကိုယ် ရေးပြီးရင် ကျန်တဲ့ Developer တွေကို Stick နဲ့ပေးတယ်။ ပြီးရင် သူတို့ရေးထားတဲ့ဟာကိုလည်း Stick နဲ့ ပြန်ယူပြီး ကိုယ့်ကုဒ်တွေထဲထည့်တယ်။ အမြဲတမ်း အဲ့လိုပဲ လုပ်တယ်။

ဒီလို Memory Stick နဲ့ အလုပ်လုပ်နေကြတာက နောက်ပိုင်းမှာ တော်တော်လေး အဆင်မပြေဖြစ်လာတယ်။ ကိုယ်က ဘယ်နေရာတွေမှာ ဘာတွေပြင်လိုက်လဲ မသိတော့သလို ဘယ် File တွေက အသစ်လဲ၊ ဘယ်သူ့ဆီမှာ ဘယ်သူ့ရဲ့ ဘာကုဒ်တွေ ရှိသလဲမသိတော့ဘူး။ ကိုယ့်ဟာကိုယ်လည်း မသိတော့ဘူး။ ကုဒ်ရေးရတဲ့အချိန်ထက် ကုဒ်တွေ ကူးပြီး ပြန်ပေါင်းနေရတဲ့အချိန်က ပိုများနေပါတယ်။ ပြီးတော့ ကိုယ့်ကုဒ်တွေကိုယ်ပြင်ပြီးမှ မပြင်ခင်က ဟာကိုပြန်လိုချင်တာမျိုးတွေလည်း ရှိသေး။ Developer တစ်ယောက် Error ပေါင်း သောင်းခြောက်ထောင်နဲ့ ခြောက်ယောက်ဆို သောင်းခြောက်ထောင်ကို Power ၆ ထပ်တင်ထားသလိုပါပဲ။

Version Control System

ဒီပြဿနာကို ဖြေရှင်းဖို့နည်းလမ်းရှာရတော့တယ်။ အဲ့မှာ Version Control System ဆိုတာကို စပြီး ကြားဖူးတာပဲ။ Version Control System (VCS) ဆိုတာကတော့ လွယ်လွယ်ပြောရရင် ကိုယ်ရေးခဲ့တဲ့ကုဒ်ရဲ့ Code Change History တစ်ခုလုံးကို မှတ်ထားပေးတဲ့ စံနစ်တစ်ခုဖြစ်ပါ။ Code Change တွေမှတ်ထားပေးတဲ့ Special Database System တစ်ခုလို့လည်း ပြောလို့ရပါတယ်။ ကိုယ့်ကုဒ်ထဲမှာ ဘာတွေပြင်လိုက်တယ်၊ ဘယ်ဖိုင်တွေအသစ်ထည့်တယ်၊ ဘယ်ဖိုင်တွေဖျက်လိုက်တယ်ဆိုတာတွေ အားလုံးကို မှတ်ထားပေးနိုင်ပါတယ်။ မှတ်ထားရုံတင်မကပါဘူး ကိုယ့်ကုဒ်ရဲ့ History ထဲက ဘယ်အခြေအနေကိုပဲဖြစ်ဖြစ် ပြန်သွားချင်သွားလို့ရပါတယ်။

Git

ဆိုတော့ Reborn CMS Development အတွက် Version Control System တစ်ခုခုကို သုံးဖို့ ကြိုးစားရပါတယ်။ Git, Concurrent Version System (CVS), Subversion (SVN), Mercurial ... အစရှိသဖြင့်ပေါ့။ Version Control System တွေ အများကြီး ရှိပါတယ်။ အဲ့ဒီထဲကမှ ဒီနေ့ လူသုံးအများဆုံးဖြစ်တဲ့ Git ကို ရွေးချယ်ခဲ့ပါတယ်။

သမိုင်းကြောင်း

Distributed Version Control System ဖြစ်တဲ့ Git ရဲ့ သမိုင်းကြောင်းကို နည်းနည်းလောက် ပြောပြချင်ပါတယ်။ Git ကို ဖန်တီးခဲ့တဲ့သူကတော့ Linux Kernel ရဲ့ မူရင်း Developer / Creator ဖြစ်တဲ့ Linus Trovalds ပဲ ဖြစ်ပါတယ်။ သူသုံးနေကျ Version Control System က Free မရတော့တဲ့အပြင် Free ရတဲ့ VCS တွေကိုလည်း အကြိုက်မတွေ့တာနဲ့ သူ့ဟာသူ Develop လုပ်လိုက်တဲ့ Project ဖြစ်ပါတယ်။

Reborn Development ကို ဆက်ရရင် VCS ထဲမှာ Reborn ဆိုတဲ့ Repo တစ်ခု တည်ဆောက်ပြီး ကျွန်တော်တို့ရဲ့ CMS ကို ဆက်ပြီး Develop လုပ်တယ်ဆိုပါတော့။ ယျေဘုယျအားဖြင့်တော့ VCS မှာ Project တစ်ခုကို Repo (Repository) တစ်ခုအနေနဲ့ ယူဆလို့ရပါတယ်။ ဒီ Repo အောက်မှာ ကိုယ့် Project ရဲ့ History တွေ ရှိနေပါတယ်။

Commit

History တွေ အားလုံး ရှိနေတယ်ဆိုပေမယ့် စာတစ်လုံးရေး တစ်ခါလိုက်မှတ်ဆိုတာမျိုး အလိုအလျှောက် လိုက်မှတ်နေတယ်လို့ မထင်စေချင်ပါဘူး။ ကိုယ်လိုချင်တဲ့အခြေအနေမှာ ကိုယ့်ဟာကိုယ် Save လုပ်ရပါတယ်။ ဒါကို VCS မှာ commit လုပ်တယ်လို့ ခေါ်ပါတယ်။ ဥပမာအားဖြင့် Reborn အတွက် Blog Post Create ဆိုတဲ့ Feature တစ်ခုရေးပြီးတဲ့အခါမှာ VCS ထဲမှာ Commit လုပ်လိုက်ပါတယ်။​ ဒါဆိုရင် အဲ့ဒီအခြေအနေမှာရှိတဲ့ ကုဒ်တွေအကုန်လုံး History တစ်ခုအနေနဲ့ VCS ထဲမှာ ရှိနေပါမယ်။ တစ်ကြောင်းရေး တစ်ခါ Commit လုပ်မလား၊​ တစ်လုံးရေး တစ်ခါ Commit လုပ်မလားဆိုတာကတော့ ကိုယ့်ရဲ့ သဘောအတိုင်းပါပဲ။

ဒီနေရာမှာလည်း တစ်ခု သတိထားရမှာက Commit လုပ်တယ်ဆိုတိုင်း ကိုယ့် Project ထဲက ရှိသမျှ ကုဒ်အပြောင်းအလဲတိုင်းကို အလိုအလျှောက် သိမ်းသွားမှာ မဟုတ်ပါဘူး။ ကိုယ် Commit လုပ်ချင်တဲ့ File ကို ကိုယ့်ဟာကိုယ် ရွေးပေးရပါတယ်။ အပေါ်က ဥပမာကို ဆက်ပြောရမယ်ဆိုရင် Reborn အတွက် ကျွန်တော်ရေးထားတဲ့ ကုဒ်က Blog Post Create တစ်ခုတည်း မဟုတ်ပါဘူး။ Comment Create Feature လည်း တစ်ဝက်တစ်ပျက် ရေးလက်စ ဖြစ်နေပါတယ်။​ အဲ့ဒီထဲကမှ Blog Post Create Feature နဲ့ ပတ်သက်တဲ့ File တွေကိုပဲ ရွေးပြီး Commit လုပ်ပါတယ်။ ဒါကြောင့် တစ်ချိန်ချိန်မှာ History အနေနဲ့ ဒီ Commit ကို ပြန်လာတဲ့အခါ Blog Post Create အတွက် ရေးထားတဲ့ ကုဒ်တွေကိုပဲ ပြန်ရပါလိမ့်မယ်။

Push

Reborn CMS ကို တစ်ယောက်တည်း Develop လုပ်တာမဟုတ်တဲ့အတွက် ကိုယ်ရေးတဲ့ ကုဒ်တွေက ကိုယ့်တစ်ယောက်တည်းမှာ ရှိနေလို့ မဖြစ်ပါဘူး။ ဒါကြောင့် Git Repository တွေကို Manage လုပ်နိုင်မယ့် Online Tools တစ်ခုကို သုံးရပါတယ်။ ဒီလိုသုံးတဲ့အခါမှာ ခုနက Commit လုပ်ထားတဲ့ Code တွေကို Online ပေါ်မှာပါ သွားပြီး Save ပေးရပါတယ်။ ဒါမှသာ တခြား Developer တွေအနေနဲ့ ကိုယ့်ရဲ့ Code ကို မြင်ရ၊ သုံးလို့ရမှာ ဖြစ်ပါတယ်။ ဒီလို ကိုယ့်ရဲ့ Commit တွေ Online ပေါ် သွား Save တဲ့ လုပ်ငန်းစဉ်ကို Push လုပ်တယ်လို့ ခေါ်ပါတယ်။

Pull

Push လုပ်လိုက်လို့ ကိုယ့်ရဲ့ Commit တွေအကုန်လုံး Online ပေါ်ရောက်သွားရောက်သွားတာတော့မှန်ပါတယ်။​ တခြား Developer တစ်ယောက်အနေနဲ့ ဒီ Commit (ကိုယ့်ရဲ့ Code History) တွေကို သူ Develop လုပ်နေတဲ့ Local Machine ထဲကို ပြန် Download ဆွဲဖို့ လိုပါတယ်။​ ဒါမှသာ ဒီ Project ကိုရေးနေတဲ့ တခြား Developer တွေ ရေးထားတဲ့ Code တွေအကုန်လုံး ကိုယ့်ရဲ့ Project ထဲကို အလိုအလျှောက် ရောက်လာမှာ ဖြစ်ပါတယ်။ ဒီလို Commit တွေ Download ဆွဲတဲ့ လုပ်ငန်းစဉ်ကို Pull လုပ်တယ်လို့ ခေါ်ပါတယ်။

လုပ်ငန်းစဉ်တစ်ခုလုံးကို အကျဉ်းချုပ် ပြန်ပြောရရင် Pull လုပ်တယ်၊ Develop လုပ်တယ်၊​ Commit လုပ်တယ်၊ Push လုပ်တယ်။ ပြီးရင် Pull က ပြန်စတယ်၊ Develop, Commit, Push လုပ်တယ်။ အောက်မှာ ပြထားတဲ့ပုံကို ကြည့်ရင် ပိုပြီး မြင်သာပါလိမ့်မယ်။

Branch

ဒီလိုနဲ့ Reborn ကို Develop လုပ်လာတာ Beta Version တစ်ခု ထုတ်နိုင်တဲ့ အခြေအနေကို ရောက်လာပါတယ်။ Version တစ်ခု Release လုပ်လိုက်ပြီးဆိုတဲ့အတွက် ကျွန်တော်တို့အနေနဲ့ ဒီ Version မှာ ရှိနေတဲ့ Code တွေကို ဆက်ပြီး ပြင်နေ၊ Develop လုပ်နေလို့ မဖြစ်တော့ပါဘူး။ Error Fix, Bug Fix ကလွဲလို့ ဒီကုဒ်တွေကို မတို့မထိဘဲ ထားရပါတော့မယ်။ ဒါဆိုရင် နောက်ထပ် Repo တစ်ခု ထပ်ဆောက်ရမှာလားလို့ ထင်စရာရှိပါတယ်။ ဒီလိုလုပ်စရာ မလိုပါဘူး။ ကျွန်တော်တို့အနေနဲ့ Version Release လုပ်ထားတဲ့ Code တွေကို သီးသန့်ထားခဲ့ပြီး နောက်ထပ် Develop လုပ်စရာရှိတာတွေကိုလည်း သီးခြား ဆက်ပြီး Develop လုပ်နေလို့ရပါတယ်။ အဲ့ဒီလို လုပ်တာကို Branch ခွဲတယ်လို့ ခေါ်ပါတယ်။ v-0.1.0 beta ဆိုတဲ့ Branch ရယ် development ဆိုတဲ့ Branch ရယ် ခွဲထုတ်လိုက်ပါတယ်။ လုပ်စရာရှိတဲ့ Development Process ကို development branch မှာပဲ ဆက်ပြီး လုပ်နေပါတယ်။ Beta Version ကို စမ်းချင်တယ်ဆိုရင်တော့ v-0.1.0 beta ဆိုတဲ့ Branch ကနေယူစမ်းလို့ရပါတယ်။

Merge

development branch မှာ Reborn ကို ဆက်ပြီး Develop လုပ်နေရင်းနဲ့ပဲ Beta Version မှာ Error တစ်ခုတွေ့ကြောင်း User တစ်ယောက်ဆီက Review ရပါတယ်။ Blog Post တွေကို Update လုပ်လို့မရဘဲ Error တက်နေတာပါ။ ဒါနဲ့ v-0.1.0 beta ဆိုတဲ့ Branch ကို ပြန်သွားပြီး အဲ့ဒီ Error ကို Fix လုပ်ရပါတယ်။ beta branch ကို သီးသန့်ထားခဲ့ပြီး development branch မှာ ဆက်ပြီး Develop လုပ်နေတာ ဖြစ်လို့ beta branch မှာ ပြင်ပြီးရင် development branch မှာလည်း လိုက်ပြင်ဖို့ လိုပါတယ်။ beta မှာ ပြင်လိုက်တဲ့ ကုဒ်တွေကို Manually အကုန်ကူးပြီး development ထဲ ပြန်လာထည့်စရာ မလိုပါဘူး။ Branch တစ်ခုက Commit ကို တခြား Branch တစ်ခုထဲ ပြန်ပေါင်းထည့်တဲ့ Feature ကို Merge လုပ်တယ်လို့ ခေါ်ပါတယ်။

နိဂုံး

ဒီလောက်ဆိုရင်တော့ Git အတွက် အခြေခံအချက်တွေ ခြုံငုံမိပြီလို့ ထင်ပါတယ်။ ပြောခဲ့တာတွေက လုံဝအခြေခံတွေ၊ ယျေဘုယျတွေဖြစ်တဲ့အတွက် ထဲထဲဝင်ဝင် သိနိုင်ဖို့ ကိုယ်တိုင်ဆက်ပြီး လေ့လာစေချင်ပါတယ်။ Git အသုံးပြုပုံနဲ့ command တွေကိုတော့ သီးသန့် မှတ်စုတစ်ခုအနေနဲ့ ထပ်ပြီး ရေးနိုင်ဖို့ ကြိုးစားနေပါတယ်။

Bonus

Bonus အနေနဲ့ပြောချင်တာကတော့ Git နဲ့ Github ကိစ္စပါ။ Developer တော်တော်များများက Git နဲ့ Github ကို မကွဲပြားဘူး ဖြစ်နေကြပါတယ်။ အပေါ်မှာ တစ်လျှောက်လုံး ပြောခဲ့တာတွေက Git အကြောင်းပါ။ Github မဟုတ်ပါဘူး။ Github ဆိုတာက Git Repository နဲ့ Git ရဲ့ Feature တွေကို Manage လုပ်လို့ရတဲ့ Cloud Based Platform တစ်ခု ဖြစ်ပါတယ်။ Github လိုပဲ Git Repository တွေကို Manage လုပ်လို့ရတဲ့ Platform တွေ ရှိပါသေးတယ်။ အသုံးများတာကတော့ GitLab နဲ့ Bitbucket ပါ။

အဆုံးထိ စိတ်ရှည်လက်ရှည် ဖတ်ပေးတဲ့အတွက် ကျေးဇူးတင်ပါတယ်။