လွယ်လွယ်ပြောရရင် Git Branch ဆိုတာ Code ရဲ့ မိတ္တူတစ်ခုကို ခွဲထုတ်ပြီး သီးသန့်စမ်းသပ်တဲ့ လမ်းကြောင်းပါ။ Merge Conflict ဆိုတာ အဲဒီလမ်းကြောင်းနှစ်ခုကို ပြန်ပေါင်းတဲ့အခါ နှစ်ဖက်စလုံးက တစ်နေရာတည်းကို မတူညီစွာ ပြင်ထားမိလို့ Git က ဘယ်ဟာကို ယူရမလဲ မဆုံးဖြတ်နိုင်တော့တဲ့ အခြေအနေပါ။
ကျွန်တော် ဒါကို စားသောက်ဆိုင်နဲ့ ယှဉ်ပြီး နားလည်သွားတယ်။ ဆိုင်ရဲ့ အဓိက Menu (Main Branch) က ရှိနေတယ်။ စားဖိုမှူးတစ်ယောက်က Menu အသစ်ကို စမ်းချင်တယ်၊ ဒါပေမယ့် အဓိက Menu ကို တိုက်ရိုက်ပြင်လိုက်ရင် ဖောက်သည်တွေက အမှားစားမိသွားနိုင်တယ်။ ဒါကြောင့် Menu ရဲ့ မိတ္တူတစ်ခုကို ယူပြီး သီးသန့်စမ်းတယ်။ အဆင်ပြေမှ အဓိက Menu ထဲ ပြန်ထည့်တယ်။ အဲဒီ မိတ္တူက Branch ပါ။ စားဖိုမှူး နှစ်ယောက်က Menu မိတ္တူ နှစ်စောင်ကို ယူပြီး ဟင်းတစ်မျိုးတည်းရဲ့ စျေးနှုန်းကို မတူညီစွာ ပြင်ထားမိရင်၊ ပြန်ပေါင်းတဲ့အခါ ဘယ်စျေးကို ယူရမလဲ ဆိုင်ရှင်က ဆုံးဖြတ်ရတယ်။ အဲဒါက Merge Conflict ပါ။
Branch ကို ဘာလို့ သုံးတာလဲ?
Team နဲ့ အလုပ်လုပ်တဲ့အခါ Branch မသုံးဘဲ Main Branch ထဲ တိုက်ရိုက်ရေးရင် ပျက်စီးဖို့ အရမ်းလွယ်ပါတယ်။ တစ်ယောက်က Bug ပြင်နေတုန်း၊ နောက်တစ်ယောက်က Feature အသစ်ထည့်နေရင် Code က အမြဲ မတည်မငြိမ်ဖြစ်နေမယ်။ Branch သုံးတော့ အကျိုးကျေးဇူးတွေက ဒါတွေပါ။
Feature တစ်ခုချင်းစီကို သီးသန့် Branch တစ်ခုနဲ့ လုပ်တယ် — ဥပမာ feature/login-page ဆိုတဲ့ Branch က Login Page အတွက်သီးသန့်၊ fix/payment-bug က Payment Bug အတွက်သီးသန့်ပေါ့။
Main Branch က အမြဲ အလုပ်လုပ်တဲ့ အခြေအနေမှာ ရှိနေတယ်။ တစ်ခုခု ပျက်သွားလည်း Main က မထိဘူး။
စမ်းသပ်ပြီး မအောင်မြင်တဲ့ အကြံကို Branch ကို ဖျက်လိုက်ရုံပဲ။ Main ကို လုံးဝ မထိခိုက်ဘူး။
Pull Request နဲ့ Code Review လုပ်ဖို့ လွယ်တယ်။ Branch တစ်ခုရဲ့ ပြောင်းလဲမှုတွေကို တစ်စုတစ်စည်းတည်း ပြန်ကြည့်လို့ရတယ်။
Branch အသစ်လုပ်ဖို့က git checkout -b feature/login-page ဒါမှမဟုတ် git switch -c feature/login-page တစ်ကြောင်းတည်းပါ။ ပြီးရင် အဲဒီ Branch ထဲမှာ စိတ်ကြိုက် Code ရေး၊ Commit လုပ်သွားရုံပဲ။
Merge Conflict က ဘယ်အချိန်ဖြစ်တာလဲ?
Conflict ဆိုတာ အမြဲတမ်း မဖြစ်ပါဘူး။ နှစ်ယောက်က ဖိုင်မတူတဲ့ နေရာတွေကို ပြင်ရင် Git က အလိုလို ပေါင်းပေးလိုက်နိုင်တယ်။ Conflict ဖြစ်တာက ဒီအခြေအနေမျိုးမှာပါ။
လူနှစ်ယောက်က ဖိုင်တစ်ဖိုင်တည်းရဲ့ စာကြောင်းတစ်ကြောင်းတည်းကို မတူညီစွာ ပြင်ထားမိတဲ့အခါ။
တစ်ယောက်က ဖိုင်ကို ဖျက်ပြီး နောက်တစ်ယောက်က အဲဒီဖိုင်ကိုပဲ ပြင်ထားမိတဲ့အခါ။
တစ်ယောက်က ဖိုင်ကို နေရာပြောင်းပြီး နောက်တစ်ယောက်က နေရာအဟောင်းမှာပဲ ပြင်ထားတဲ့အခါ။
Conflict ဖြစ်တဲ့အခါ Git က ဖိုင်ထဲမှာ ဒီလိုမျိုး အမှတ်အသားတွေ ထည့်ပေးလိုက်ပါတယ်။
<<<<<<< HEAD
သင့်ဘက်က Code
=======
တစ်ဖက်က Code
>>>>>>> feature/login-page
<<<<<<< နဲ့ ======= ကြားက သင့်ဘက်က Code၊ ======= နဲ့ >>>>>>> ကြားက ပေါင်းလာတဲ့ Branch ဘက်က Code ပါ။ သင်က ဘယ်ဟာကို ထားမလဲ၊ နှစ်ခုလုံးကို ပေါင်းမလား၊ ဒါမှမဟုတ် လုံးဝ အသစ်ရေးမလား ဆုံးဖြတ်ပြီး အမှတ်အသားတွေကို ဖျက်ပေးရပါတယ်။ ပြီးရင် git add လုပ်ပြီး Commit လုပ်လိုက်ရင် Conflict ရှင်းသွားပါပြီ။
Conflict ကို ဘယ်လို ရှောင်မလဲ?
Conflict က မကောင်းတဲ့ အရာမဟုတ်ပါဘူး။ Team နဲ့ အလုပ်လုပ်ရင် သဘာဝကျကျ ဖြစ်တတ်တဲ့ ကိစ္စပါ။ ဒါပေမယ့် အကြိမ်ရေ နည်းအောင် ဒီလိုလုပ်လို့ရပါတယ်။
Branch ကို ကြာကြာမထားပါနဲ့။ တစ်ပတ်လောက် သီးသန့်နေပြီးမှ ပြန်ပေါင်းရင် Conflict များလာနိုင်တယ်။ မကြာခဏ ပြန်ပေါင်းပါ။
မပေါင်းခင် Main Branch ရဲ့ အသစ်ဆုံးအခြေအနေကို အရင်ယူပါ။ git pull origin main ဒါမှမဟုတ် git rebase main လုပ်ပြီးမှ ပေါင်းပါ။
အဖွဲ့ထဲမှာ ဘယ်သူက ဘယ်ဖိုင်ကို ကိုင်နေတယ်ဆိုတာ ပြောထားပါ။ တစ်ဖိုင်တည်းကို နှစ်ယောက် တစ်ပြိုင်နက် မကိုင်ရင် Conflict အတော်လေး နည်းသွားမယ်။
Commit ကို သေးသေးလေးတွေ ခွဲလုပ်ပါ။ ပြောင်းလဲမှုကြီးတစ်ခုကို Commit တစ်ခုတည်းနဲ့ မလုပ်ပါနဲ့။
အရေးကြီးဆုံးအချက်က Conflict ဖြစ်တဲ့အခါ မကြောက်ပါနဲ့။ Git က သင့်ရဲ့ Code ကို ဖျက်ပစ်တာ မဟုတ်ပါဘူး။ နှစ်ဖက်လုံးရဲ့ Code ကို ပြပေးပြီး “သင်ဆုံးဖြတ်ပါ” လို့ ပြောနေတာပါ။ အေးအေးဆေးဆေး ဖတ်ကြည့်၊ ဘယ်ဟာက မှန်တယ်ဆိုတာ ရွေးပြီး ရှင်းလိုက်ရုံပဲ။
ကျွန်တော်ကိုယ်တိုင်လည်း ပထမဆုံး Conflict တွေ့တုန်းက လန့်သွားဖူးတယ်။ ဖိုင်ထဲမှာ <<<<<<< တွေ မြင်တော့ Code ပျက်သွားပြီထင်ခဲ့တာ။ တကယ်တော့ အဲဒါက Git ရဲ့ “ဒီမှာ ရွေးစရာရှိတယ်” ဆိုတဲ့ သတိပေးချက်သက်သက်ပါ။ နောက်တစ်ခါ Conflict တွေ့ရင် ရယ်မောပြီး ရှင်းလိုက်ပါ။ Team နဲ့ အလုပ်လုပ်နေတယ်ဆိုတဲ့ သက်သေပါပဲ။ 🙂
