Git Rebase vs Merge: เข้าใจความแตกต่างและเลือกใช้ให้ถูกงาน

ทีมที่ทำงานร่วมกันบน branch เดียวกันมักเจอคำถามนี้ตลอด: จะรวมงานจาก feature branch กลับเข้า main ด้วย merge หรือ rebase ดี บทความนี้สรุปสิ่งที่เกิดขึ้นจริงเบื้องหลังทั้งสองคำสั่ง เพื่อให้ตัดสินใจได้ถูกงาน ไม่ใช่แค่ท่องจำว่า "team เราใช้อะไร"

Merge ทำงานยังไง

git merge สร้าง commit ใหม่ที่มี parent สองอัน (merge commit) โดยไม่แก้ประวัติ commit เดิมเลย

git checkout main
git merge feature/login

ข้อดีคือปลอดภัย ไม่ rewrite history ที่คนอื่นอาจ pull ไปแล้ว แต่แลกมาด้วย commit graph ที่ดูรกเมื่อมีหลาย feature branch มารวมกันพร้อมกัน

Rebase ทำงานยังไง

git rebase เอา commit ทั้งหมดใน branch ปัจจุบัน "เล่นซ้ำ" (replay) ต่อจาก commit ล่าสุดของ branch เป้าหมาย ผลคือได้ประวัติเส้นตรง ไม่มี merge commit

git checkout feature/login
git rebase main

ข้อควรระวัง: rebase เขียน commit hash ใหม่ทั้งหมด ถ้า branch นั้นถูก push ไปแล้วและมีคนอื่น pull ไปทำงานต่อ การ rebase แล้ว force push จะทำให้ history ของคนอื่นขัดแย้งกับของเรา

เมื่อไหร่ควรใช้อะไร

สถานการณ์	แนะนำ
Feature branch ส่วนตัว ยังไม่ share กับใคร	`rebase` ได้อิสระ ก่อน merge เข้า main
Branch ที่มีคนอื่น push ร่วมด้วยแล้ว	`merge` หรือ `rebase` แบบระวัง (`--force-with-lease` เท่านั้น)
ต้องการเก็บบริบทว่า feature ไหนรวมตอนไหน	`merge` (มี merge commit เป็นหลักฐาน)
ต้องการ history เส้นตรง อ่าน `git log` ง่าย	`rebase` ก่อน merge แบบ fast-forward

กับดักที่พบบ่อย

force push ทับ branch กลาง — ใช้ git push --force-with-lease แทน --force เสมอ มันจะ reject ถ้ามีคน push ใหม่ไปแล้วที่เรายังไม่เห็น
rebase branch ที่คนอื่นใช้งานร่วมอยู่ — กฎง่ายๆ คือ อย่า rebase อะไรที่ไม่ใช่ของเราคนเดียว
แก้ conflict ซ้ำหลายรอบระหว่าง interactive rebase — ใช้ git rebase --continue ทีละ commit และเปิด git config rerere.enabled true เพื่อให้ git จำวิธีแก้ conflict แบบเดิมที่เคยทำไว้

รายละเอียดเพิ่มเติมของทุกคำสั่งดูได้ที่ Git documentation อย่างเป็นทางการ