Rebase နှင့် Merge vs Rebase

နားလည်ထားရမယ့် အချက်

Rebase ဆိုတာ သင့် branch ပေါ်က commit တွေကို တစ်ခုချင်းစီယူပြီး base commit အသစ်တစ်ခု (များသောအားဖြင့် main ရဲ့ နောက်ဆုံး commit) ပေါ်မှာ replay လုပ်ပေးတဲ့ Git operation တစ်ခုပါ။ merge commit ဖန်တီးမယ့်အစား branch ကို base အသစ်ကနေ အစကတည်းက အလုပ်စလုပ်ခဲ့သလိုပုံစံဖြစ်အောင် ပြန်ရေးပေးလို့ merge graph အစား linear history ဖြစ်လာပါတယ်။

ပြဿနာက commit တစ်ခုကို replay လုပ်တဲ့အခါ original commit object ကို ပြန်သုံးတာ မဟုတ်ပါဘူး — parent ပြောင်းသွားလို့ hash အသစ်ရှိတဲ့ commit အသစ်တစ်ခု ဖန်တီးလိုက်တာပါ။ rebase လုပ်လိုက်တဲ့ branch ပေါ်က commit တိုင်းဟာ code အတိအကျ တူနေပေမယ့် hash အသစ်ရရှိသွားပါတယ်။

နည်းလမ်း	ဘာဖြစ်လဲ
Merge	Non-destructive — commit တွေကို ဘယ်တော့မှ ပြန်မရေးဘဲ branch history အပြည့်အစုံ (side branch အားလုံးအပါအဝင်) ကို ထိန်းသိမ်းပေမယ့် merge commit တွေပိုများပြီး graph ရှုပ်တတ်ပါတယ်။
Rebase	Review လုပ်ရလွယ်တဲ့ linear history သန့်ရှင်းတစ်ခု ရရှိပေမယ့် replay လုပ်တဲ့ commit တိုင်းရဲ့ hash ကို ပြန်ရေးလိုက်ပါတယ်။

ဘယ်နည်းလမ်းမှ အမြဲမှန်တယ်လို့ မဆိုနိုင်ပါဘူး — team အများစုက feature branch တွေကို main ထဲ merge လုပ်ပေမယ့် push မလုပ်ခင် local အလုပ်ကို rebase အလွတ်လုပ်လေ့ရှိကြပါတယ်။

Shared history ကို ဘယ်တော့မှ rebase မလုပ်ပါနဲ့

Commit တစ်ခုကို တခြားသူတွေ pull ဆွဲနေတဲ့ branch ပေါ် push လုပ်ပြီးသားဆိုရင် ဒီ commit ကို rebase ပြန်လုပ်ရင် hash အသစ်ရှိတဲ့ commit ထပ်တွေ ဖြစ်ပေါ်လာပြီး ရှိပြီးသားသူတွေအတွက် ပြဿနာဖြစ်စေပါတယ်။ local ဒါမှမဟုတ် မ push ရသေးတဲ့ commit တွေကိုသာ rebase လုပ်ပါ — team တစ်ခုလုံးက force-push အတွက် ရှင်းရှင်းလင်းလင်း သဘောတူထားမှသာ ချက်လွှတ်ပါ။

Rebase: commit အစီအစဉ်တစ်ခုကို base commit တစ်ခုကနေ တစ်ခြား base တစ်ခုပေါ် replay လုပ်ပြီး content အတိအကျတူပေမယ့် commit object အသစ် (hash အသစ်) ဖန်တီးပေးတဲ့ Git operation တစ်ခု။

text

REBASE: REPLAYING COMMITS ONTO A NEW BASE
-----------------------------------------
BEFORE REBASE

main:     A---B---C
               \
feature:        D---E

AFTER REBASE (feature rebased onto main)

main:     A---B---C
                    \
feature:             D'---E'

Same code changes, new commit hashes: D' and E' are new objects.

လက်တွေ့ scenario နဲ့ ချိတ်ကြည့်မယ်

ဒီ ဥပမာမှာ main နဲ့ feature branch နှစ်ခုလုံး သီးခြားစီ ရှေ့ဆက်သွားပြီး တကယ်ကွဲထွက်တဲ့ repo သေးသေးလေးတစ်ခု တည်ဆောက်ပြီးနောက် feature branch ကို main အသစ်ပေါ် rebase လုပ်ပါတယ်။

ကွဲထွက်စေခြင်း

main ပေါ်မှာ A နဲ့ B commit လုပ်ပြီး B ကနေ feature branch ခွဲထုတ်ကာ D၊ E commit တွေထည့်ပါ၊ ထိုအတောအတွင်း main ပေါ်မှာလည်း C commit အသစ်ရလာပါတယ်။

rebase မလုပ်ခင် စစ်ဆေးခြင်း

feature ပေါ်က git log --oneline က A, B, D, E ကိုပဲ ပြပြီး C ဖြစ်ခဲ့တာကို မသိပါဘူး။

Rebase လုပ်ခြင်း

git rebase main က D နဲ့ E ကို C ရဲ့အပေါ်မှာ ပြန် replay လုပ်ပြီး hash အသစ်ရှိတဲ့ D' နဲ့ E' ကို ဖန်တီးပေးပါတယ်။

Conflict ဖြစ်ရင်

replay လုပ်နေစဉ် conflict ဖြစ်ရင် Git ရပ်ပေးပြီး ဖြေရှင်းခိုင်းပါတယ်၊ ပြီးရင် git rebase --continue နဲ့ commit တစ်ခုချင်းစီ ရှေ့ဆက်နိုင်ပါတယ်။

Rebase က commit တွေကို base အသစ်ပေါ် replay လုပ်ပြီး code အတူတူဖြစ်ပေမယ့် replay လုပ်တဲ့ commit တိုင်းအတွက် hash အသစ် ဖြစ်ပေါ်စေပါတယ်။
Merge က history ကို ထိန်းသိမ်းပြီး ဘယ်တော့မှ commit မပြန်ရေးပါဘူး၊ rebase ကတော့ linear history သန့်ရှင်းရရှိပေမယ့် hash ပြန်ရေးလိုက်ပါတယ် — ဘယ်ဟာမှ အမြဲပိုကောင်းတယ်လို့ မဆိုနိုင်ပါဘူး။
team တစ်ခုလုံးက force-push အတွက် ရှင်းရှင်းလင်းလင်း သဘောတူထားမှသာ push ပြီးသား ဒါမှမဟုတ် shared commit တွေကို rebase မလုပ်သင့်ပါဘူး။

Shared history ကို ဘယ်တော့မှ rebase မလုပ်ပါနဲ့

အတူတူ စမ်းရေးကြည့်မယ်

bash

export GIT_AUTHOR_NAME="Thuta Learner"
export GIT_AUTHOR_EMAIL="learner@example.com"
export GIT_COMMITTER_NAME="Thuta Learner"
export GIT_COMMITTER_EMAIL="learner@example.com"

git init
export GIT_AUTHOR_DATE="2026-01-01T09:00:00"
export GIT_COMMITTER_DATE="2026-01-01T09:00:00"
echo "# Project" > README.md
git add README.md
git commit -m "A: initial commit"

export GIT_AUTHOR_DATE="2026-01-01T10:00:00"
export GIT_COMMITTER_DATE="2026-01-01T10:00:00"
echo "core logic" > app.js
git add app.js
git commit -m "B: add app.js"

git checkout -b feature

export GIT_AUTHOR_DATE="2026-01-01T11:00:00"
export GIT_COMMITTER_DATE="2026-01-01T11:00:00"
echo "feature part 1" > feature.js
git add feature.js
git commit -m "D: start feature"

export GIT_AUTHOR_DATE="2026-01-01T12:00:00"
export GIT_COMMITTER_DATE="2026-01-01T12:00:00"
echo "feature part 2" >> feature.js
git add feature.js
git commit -m "E: finish feature"

git log --oneline

git checkout main
export GIT_AUTHOR_DATE="2026-01-01T13:00:00"
export GIT_COMMITTER_DATE="2026-01-01T13:00:00"
echo "hotfix" > hotfix.js
git add hotfix.js
git commit -m "C: hotfix on main"

git checkout feature
git rebase main

git log --oneline

You should see

rebase မလုပ်ခင် feature branch ပေါ်မှာ git log --oneline ကို run ရင်:

d0454cd E: finish feature
903b723 D: start feature
3d4128d B: add app.js
ad48fd4 A: initial commit

main ပေါ်မှာ hotfix commit (C) ထည့်ပြီး feature ကို git rebase main လုပ်ပြီးနောက်မှာတော့:

13d1c09 E: finish feature
bdf110d D: start feature
5c375f6 C: hotfix on main
3d4128d B: add app.js
ad48fd4 A: initial commit

D နဲ့ E ကို C ရဲ့ အပေါ်မှာ ပြန် replay လုပ်ပြီး hash အသစ် (13d1c09, bdf110d) ရရှိသွားပါတယ်၊ A၊ B၊ C တို့ကတော့ hash အဟောင်းအတိုင်းပဲ ရှိနေပါတယ်။

၅ မိနစ် စမ်းကြည့်

ကိုယ်ပိုင် repo တစ်ခုမှာ ကွဲထွက်နေတဲ့ branch နှစ်ခု (main နဲ့ commit အသစ်တွေပါတဲ့ feature branch) ဖန်တီးပြီး feature ကို main ပေါ် rebase လုပ်ပါ။ rebase မလုပ်ခင်နဲ့ လုပ်ပြီးနောက် git log --oneline --graph ကို branch နှစ်ခုလုံးမှာ run ပြီး ပုံစံပြောင်းလဲမှုကို ကြည့်ပါ။ ပြီးရင် file တူတူတစ်ခုရဲ့ line တူတူတစ်ကြောင်းကို branch နှစ်ခုလုံးမှာ မတူအောင်ပြင်ပြီး conflict အစစ်တစ်ခု ဖန်တီးကာ git rebase --continue နဲ့ ဖြေရှင်းကြည့်ပါ။

သတိလေးတစ်ချက်

team ဝင်တစ်ယောက် pull ဆွဲပြီးသား branch ကို rebase လုပ်ရင် replay လုပ်လိုက်တဲ့ commit တွေက hash အသစ်ရလို့ သူတို့ ကိုင်ဆွဲထားတဲ့ commit တွေအားလုံး တိတ်တဆိတ် ထပ်ဖြစ်သွားပါတယ် — ဒါက git command နဲ့ ဖြေရှင်းစရာမဟုတ်ဘဲ rebase မလုပ်ခင် ဆွေးနွေးဖို့ လိုအပ်ပါတယ်။

team ဝင်တွေကို အသိမပေးဘဲ rebase လုပ်ပြီးသား branch ကို shared remote ပေါ် force-push လုပ်ရင် hash အဟောင်းပေါ် အခြေခံထားတဲ့ team ဝင်တစ်ယောက်ရဲ့ လုပ်ဆောင်ဆဲ commit တွေကို တိတ်တဆိတ် ဖျက်ပစ်နိုင်ပါတယ်။

Git - git-rebase Documentation — Git & GitHub