เมื่อพัฒนาโครงการร่วมกันในทีม คำถามที่นักพัฒนาหลายคนสงสัยคือ ควรใช้ git merge หรือ git rebase ดี ทั้งสองคำสั่งมีจุดประสงค์คล้ายกันคือ นำการเปลี่ยนแปลงจาก branch หนึ่งมารวมกับอีก branch หนึ่ง แต่วิธีการทำงานและผลลัพธ์แตกต่างกันอย่างมีนัยสำคัญ บทความนี้จะอธิบายความแตกต่างและแนะนำวิธีเลือกใช้ให้ถูกต้อง

git merge คืออะไร?

git merge คือคำสั่งที่นำ commit ทั้งหมดจาก branch ต้นทางมารวมกับ branch ปลายทาง โดยสร้าง merge commit ใหม่ขึ้นมา ซึ่งเก็บประวัติว่า branch ทั้งสองถูกรวมกัน ณ จุดนั้น

# อยู่บน main branch
git checkout main

# Merge feature branch เข้ามา
git merge feature/login

ผลลัพธ์คือ Git history จะมี merge commit ที่มี 2 parent: commit สุดท้ายของ main และ commit สุดท้ายของ feature/login

ข้อดีของ git merge

• เก็บประวัติการทำงานจริงไว้ครบถ้วน (non-destructive)
• ปลอดภัย ไม่แก้ไข commit ที่มีอยู่
• เหมาะสำหรับ branch ที่ใช้ร่วมกันในทีม

ข้อเสียของ git merge

• History อาจดูรกและซับซ้อนเมื่อทำงานกับหลาย branch
• มี merge commit เพิ่มมาทุกครั้ง ทำให้ log ดูยุ่ง

git rebase คืออะไร?

git rebase คือคำสั่งที่ย้าย commit ของ branch ปัจจุบันไปต่อท้าย commit ล่าสุดของ branch เป้าหมาย โดย Git จะสร้าง commit ใหม่สำหรับแต่ละ commit เดิม ทำให้ประวัติดูเป็นเส้นตรง

# อยู่บน feature branch
git checkout feature/login

# Rebase บน main
git rebase main

ผลลัพธ์คือ commit ของ feature/login จะถูกสร้างใหม่ต่อจาก commit ล่าสุดของ main ทำให้ดูเหมือน branch แตกออกจาก main ล่าสุด

ข้อดีของ git rebase

• History เป็นเส้นตรง อ่านง่าย สะอาด
• ไม่มี merge commit ที่ไม่จำเป็น
• เหมาะสำหรับ feature branch ส่วนตัวที่ยังไม่ได้ push

ข้อเสียของ git rebase

• เขียนทับประวัติ (rewrite history) — ห้ามใช้กับ branch ที่แชร์ในทีมแล้ว
• อาจเกิด conflict หลายครั้งระหว่าง rebase
• ถ้าทำผิดพลาดอาจสูญเสีย commit

ตารางเปรียบเทียบ git merge vs git rebase

เมื่อไหร่ควรใช้ git merge?

• เมื่อ merge feature branch เข้า main หรือ develop
• เมื่อ branch ถูก push และมีคนอื่นใช้งานอยู่
• เมื่อต้องการเก็บบันทึกว่า branch ถูก merge เมื่อไหร่
• ใน CI/CD pipeline ที่ต้องการความชัดเจนของ history

เมื่อไหร่ควรใช้ git rebase?

• เมื่อต้องการอัปเดต feature branch ให้ทันกับ main ล่าสุด
• เมื่อ branch ยังเป็นของคุณคนเดียว ยังไม่ได้แชร์
• เมื่อต้องการทำความสะอาด commit ก่อน merge (interactive rebase)
• ใน open-source project ที่ maintainer ต้องการ linear history

Golden Rule: ห้าม Rebase Branch ที่ Push แล้ว

กฎสำคัญที่สุดของ git rebase คือ อย่า rebase branch ที่ push ไปแล้วและมีคนอื่นใช้ เพราะการ rebase จะสร้าง commit ใหม่ที่มี hash ต่างออกไป ทำให้ repository ของคนอื่นเกิดความขัดแย้ง

# ถ้าจำเป็นต้อง push หลัง rebase (ใช้ด้วยความระมัดระวัง)
git push --force-with-lease origin feature/my-branch

# --force-with-lease ปลอดภัยกว่า --force
# เพราะจะหยุดถ้ามีคนอื่น push ไปก่อนหน้านี้

Git Flow Branching Strategy และการเลือก Merge

เมื่อเลือก merge strategy ควรพิจารณาการใช้ Git Flow branching strategy ที่ช่วยจัดการ develop และ release branches ได้อย่างเป็นระบบ สำหรับผู้ที่ต้องการ แก้ไข merge conflicts ให้มีประสิทธิภาพ การเข้าใจทั้ง merge และ rebase จึงเป็นสิ่งจำเป็น

Interactive Rebase: เครื่องมือทำความสะอาด Commit

Interactive rebase (git rebase -i) เป็นฟีเจอร์ขั้นสูงที่ช่วยให้คุณแก้ไข commit ก่อน push ได้ เช่น รวม commit, แก้ข้อความ, หรือเรียงลำดับใหม่

# Rebase แบบ interactive ย้อนหลัง 3 commit
git rebase -i HEAD~3

# จะเปิด editor ให้เลือกว่าจะทำอะไรกับแต่ละ commit:
# pick   - ใช้ commit นี้ตามเดิม
# reword - เปลี่ยน commit message
# edit   - แก้ไข commit
# squash - รวม commit นี้เข้ากับ commit ก่อนหน้า
# drop   - ลบ commit นี้

Cherry-pick: เลือก Commit เฉพาะตัว

นอกจากการ merge และ rebase แล้ว cherry-pick ใน Git เป็นวิธีที่ให้คุณเลือก commit เฉพาะตัวจาก branch หนึ่งมาไปยัง branch อื่น โดยไม่ต้อง merge ทั้งหมด วิธีนี้มีประโยชน์สำหรับการ hotfix bug ที่พบในการ production ที่ต้องนำมาแก้ไขในทันที

Squash Merge: ลดจำนวน Commit

เมื่อจัดการ commit history git squash merge เป็นเครื่องมือที่ช่วยให้คุณรวม commit หลายตัวเป็นตัวเดียว ก่อน merge เข้า main ทำให้ history ดูสะอาดและง่ายต่อการ trace การเปลี่ยนแปลง สำหรับทีมที่ต้องการ commit history ให้กระชับและชัดเจน วิธีนี้จึงสำคัญมาก

สรุป

ไม่มีคำตอบที่ถูกหรือผิดสำหรับการเลือกระหว่าง merge และ rebase ขึ้นอยู่กับบริบทและนโยบายของทีม โดยทั่วไปแนะนำให้ใช้ merge สำหรับ production branch (main, develop) และใช้ rebase สำหรับ feature branch ส่วนตัว ก่อนจะ merge เข้า main เพื่อให้ history สะอาด

การเข้าใจการทำงานของทั้งสองวิธีจะช่วยให้คุณจัดการ Git workflow ได้อย่างมืออาชีพ และสามารถตั้งค่า pre-commit hooks เพื่อตรวจสอบคุณภาพของ commit message ได้เป็นอย่างดี ส่วนการใช้ branching strategy ที่เหมาะสม จะทำให้ทีมของคุณสามารถพัฒนาโปรเจกต์ได้อย่างเหมาะสมและลดความสับสน