Git ကို အရင်ရုံး point-star မှာ စသုံးဖူးတာပါ။ git ဆိုတာကို အရင်တုန်းကတော့ opensource တွေကို download ဆွဲချပြီး သုံးဖို့လောက်ပဲ သုံးဖြစ်တယ်။ point-star မှာ github သုံးရမယ်ဆိုတာနဲ့ github ကို လေ့လာဖြစ်တာပဲ။ github နဲ့ git အစတုန်းက လုံးဝ ကို မကွဲတာ။ github သုံးရင်းနဲ့ git နဲ့ github မတူဘူးဆိုတာ သိလာတာ။ git သုံးတတ်ပြီးနောက်ပိုင်းမှာ github မှာ opensource project တွေ တင်ဖြစ်တယ်။ သို့ပေမယ့် တစ်ယောက်တည်းပဲ ဖြစ်တဲ့အတွက် git အကြောင်းကို ကောင်းကောင်း မသိခဲ့ဘူး။ အရင်ရုံးတုန်းကလည်း တစ်ယောက်တည်းလိုလို ဖြစ်နေတဲ့အတွက် မထူးခြားလှဘူး။ backup သာသာ ရှိပါတယ်။
ဒီရုံးရောက်တော့ repo သုံးမယ် ဆိုတော့ ကျွန်တော်က bitbucket ကို recommend လုပ်ခဲ့တယ်။ သို့ပေမယ့် bitbucket က hg ပဲ support လုပ်တယ်။ ဒါကြောင့် git ထက်စာရင် hg ကို အသုံးပြုဖြစ်ခဲ့တယ်။ အခုနောက်ပိုင်း bitbucket က git support လုပ်တော့ ကျွန်တော်တို့တွေ git ကို ပြောင်းသုံးခဲ့တယ်။ hg နဲ့ git က အတူတူပဲ လို့ ဆိုလို့ရပါတယ်။ သို့ပေမယ့် ကျွန်တော်က git ကို ပိုကြိုက်တယ်။ git က data တွေကို compress လုပ်ပြီး သိမ်းထားတဲ့အတွက်ကြောင့် နေရာ သိပ်မယူဘူးလို့ ဆိုရမလိုပဲ။ Git ကို စသုံးတဲ့အချိန်မှာ ကျွန်တော်တို့ ရုံးက ၂ ယောက်တည်း မဟုတ်တော့တာအတွက်ကြောင့် hg ထက်စာရင် git အကြောင်းကို ပိုသိပါတယ်။
ရုံးမှာ နေ့စဉ် အိန္ဒိယက တင်ထားတဲ့ commit တွေကို pull လုပ်ပြီးတော့ ဘာတွေ ပြင်လိုက်လဲ။ မနေ့က သူတို့တွေ ဘာတွေ ပြီးသွားလဲဆိုတာကို ပြန်စစ်ပါတယ်။ ပြီးရင် code တွေ ကို ပြန်ပြင် push လုပ်။ တစ်ခါတစ်လေ မှာ နှစ်ယောက်လုံးရေးထားတာတွေကို merge လုပ်ရတဲ့ အခါတွေလည်းရှိတယ်။
Git ကို သုံးတဲ့ အခါမှာ Branch , Tag စတာတွေက အရေးပါပါတယ်။ Git ကို ဘယ်လို သုံးသင့်သလဲဆိုတာကို A successful Git branching model ကို ဖတ်ကြည့်သင့်ပါတယ်။
ကျွန်တော်တို့ git branch တွေကို အပေါ်က ပုံ အတိုင်း မဟုတ်ပေမယ့် အနီးစပ်ဆုံး အသုံးပြုတယ်လို့ဆိုရမယ်။ master branch မှာ stable ကို ထားပြီး development ကို branch သီးသန့် ခွဲထုတ်ထားပါတယ်။ UI Design အသစ်ပြောင်းတဲ့အခါမှာ branch အသစ် ခွဲထုတ်ပြီးတော့ ရေးပါတယ်။ ပြီးမှ အရင် branch ကို ပြန်ပြီး merge လုပ်ပါတယ်။ UI Develop အသစ်လုပ်လိုက်တဲ့အတွက်ကြောင့် code အဟောင်းတွေ သုံးမရတော့ဘူးဆိုတာ မဖြစ်တော့ဘူးပေါ့။
Project ကို Release လုပ်ပြီးတဲ့ အခါမှာတော့ Tag ထားခဲ့ပါတယ်။ Git ကို အသုံးပြုတဲ့အခါမှာ အဓိက ကောင်းတဲ့ အချက်က developer တွေ ၂ ယောက် သို့မဟုတ် ၂ ယောက်ထက် မက project မှာ ပါဝင်လာပြီဆိုရင် တော်တော်လေးကို အသုံးဝင်လှပါတယ်။ ကျွန်တော်ပြီးခဲ့ project က ရေးခဲ့တဲ့ git branch က အောက်က ပုံမှာ တစ်ပိုင်းလေး ပြထားပါတယ်။
Git ကို ကျွန်တော်တို့တွေ အရေးကြီးတာ တစ်ခုခု ပြင်လိုက်တိုင်း push လုပ်ပါတယ်။ ဘာလို့လည်း ဆိုတော့ ဘာတွေကို ပြောင်းလိုက်လဲဆိုတာကို သိနိုင်အောင်ပါ။ နောက်ပြီး git ကို commit လုပ်တိုင်း အဓိပ္ပာယ်ရှိတဲ့ comment တွေနဲ့ပဲ commit လုပ်ပါတယ်။ ဒါမှ အခြား developer က သူဘာတွေ ပြင်လိုက်တာလဲဆိုတာကို စာဖတ်လိုက်တာနဲ့ သိနိုင်မှာပါ။ Git ကို သုံးတဲ့ ကောင်းတဲ့ အချက်တစ်ခုကတော့ တစ်ခုခု မှားသွားရင် ပြန်ပြီး အရင် commit ကို Rebase ပြန်လုပ်လို့ရတာပါပဲ။ ဒါ့အပြင် ကျွန်တော်တို့တွေ commit ၂ ခု ၃ ခုလောက်ကို ပြောင်းပြီးတော့ commit တစ်ခု အနေနဲ့ ပြန်ပြောင်းလို့ရသလို commit ၁ ကိုလည်း commit ၂ ခုဖြစ်ပါတယ်ဆိုပြီး ခွဲထုတ်နိုင်ပါတယ်။ commit ကို ခွဲထုတ်တာနဲ့ merge လုပ်တာကိုတော့ မစမ်းဘူးသေးပါဘူး။
Git ကို သုံးတဲ့အခါမှာ နောက်ထပ် သဘောကျတဲ့ အပိုင်းကတော့ submodule ပါပဲ။ Submodule ဆိုတာကိုတော့ အခြား git repo ကို ဒီ git repo မှာ ယူသုံးထားတာပါပဲ။ သူက ယူသုံးထားတဲ့ git repo ကို push တွေလုပ်မနေနဲ့တော့ဘူး။
ဥပမာ။ ကျွန်တော် MKNetworkKit ကို ကျွန်တော့် project မှာ သုံးတယ်ဆိုရင်
git submodule add git://github.com/MugunthKumar/MKNetworkKit.git OtherLibrary/MKNetworkKit
push လုပ်တဲ့ အခါမှာတော့ OtherLibrary/MKNetworkKit ကို push လုပ်မနေတော့ပါဘူး။ ကျွန်တော်တို့တွေ အခြား computer တစ်ခုကနေ clone လုပ်တာပဲ ဖြစ်ဖြစ် pull လုပ်တာပဲ ဖြစ်ဖြစ် submodule တွေကို ပြန်ပြီးတော့ pull လုပ်ပေးရပါတယ်။
git submodule update –init
ဆိုတာနဲ့ submodule တွေ အကုန် ဆွဲချပါတယ်။ တစ်ခါတစ်လေ MKNetworkKit က update လုပ်လိုက်တာဖြစ်ဖြစ် အခြား submodule က update လုပ်တာဖြစ်ဖြစ် git ကို update လုပ်ချင်တယ်ဆိုရင်
git submodule foreach git pull
ဆိုပြီး ခေါ်သုံးပါတယ်။ ဒါဆိုရင် submodule တွေ အားလုံးကို pull လုပ်ပြီး update လုပ်သွားမှာပါ။ ဒါဟာ အရမ်းကောင်းပါတယ်။ ကျွန်တော်တို့တွေ library တစ်ခု update လုပ်တိုင်း သွားပြီးတော့ zip file ကို ဆွဲချ။ replace လုပ်။ စတာတွေ သက်သာသွားပါတယ်။
နောက်ဆုံး ပြောချင်တာကတော့
Git ဆိုတာက backup တစ်ခုတည်း အတွက်မဟုတ်ပါဘူး။