การทำงานร่วมกันในทีมด้วย Git หนึ่งในคำถามยอดฮิตที่ทำให้ทั้งมือใหม่และมือเก๋าถกเถียงกันอยู่เสมอคือ “คำสั่ง Merge กับ Rebase ต่างกันยังไง แล้วควรใช้แบบไหนดี?”
ทั้งสองคำสั่งมีเป้าหมายเดียวกันคือ การนำโค้ดจาก branch หนึ่งมารวมกับอีก branch หนึ่ง แต่สิ่งที่ต่างกันอย่างสิ้นเชิงคือ การจัดการ History (ประวัติการแก้ไข)
Git Merge: รวมแบบรักษาประวัติเดิมไว้ครบถ้วน
git merge จะนำประวัติการทำ commit ทั้งหมดของทั้งสอง branch มาผสานรวมกัน โดยสร้าง “Merge Commit” ขึ้นมาใหม่ 1 อันเพื่อเป็นจุดเชื่อมต่อ
git checkout main
git merge feature-branch
- ข้อดี
- ปลอดภัย: ไม่มีการแก้ไขประวัติ commit เก่า (Non-destructive)
- ตรงตามความเป็นจริง: บันทึกชัดเจนว่าใครทำงานส่วนไหน เสร็จเมื่อไหร่ และถูกนำมารวมกันตอนไหน
- ข้อเสีย
- Commit History รก: ถ้าในทีมมีคนกด merge บ่อย ๆ เส้นกราฟของ Git จะพันกันยุ่งเหยิงเหมือนสายไฟ (เรียกว่า Spaghetti History) อ่านยากมาก
Git Rebase: ย้ายฐานเพื่อประวัติที่เป็นเส้นตรงเรียบกริบ
git rebase ย่อมาจาก “Re-base” หรือการเปลี่ยน “จุดเริ่มต้น (Base)” ของ branch เรา ไปต่อท้าย commit ล่าสุดของ branch ที่เราจะไปรวม
พูดง่ายๆ คือ มันจะหยิบเอา commit ทั้งหมดที่เราทำใน feature-branch ไป ถอดออกชั่วคราว แล้วเอาไป ต่อท้ายสุด ของ main ทำให้ประวัติการแก้โค้ดกลายเป็นเส้นตรงสวยงาม
git checkout feature-branch
git rebase main
- ข้อดี
- History สะอาด เรียบง่าย: กราฟ Git เป็นเส้นตรงเดี่ยว อ่านง่าย ไล่ดูการเปลี่ยนแปลงย้อนหลังได้สบาย
- ไม่มี Merge Commit รบกวน: ไม่สร้าง commit ขยะโดยไม่จำเป็น
- ข้อเสีย
- บิดเบือนเวลาจริง: commit ID จะถูกสร้างขึ้นใหม่ ทำให้ดูเหมือนเราเพิ่งเขียนโค้ดทั้งหมดเสร็จสด ๆ ร้อน ๆ บน main ล่าสุด
- อันตรายหากใช้ผิดที่: หากไป rebase บน branch ที่แชร์กับคนอื่น อาจทำให้เพื่อนในทีมสับสนและเกิด Conflict มหาศาล
เปรียบเทียบภาพรวม: Merge vs Rebase
| หัวข้อ | Git Merge | Git Rebase |
| ลักษณะประวัติ (History) | เป็นกิ่งก้านสาขา มี Merge Commit | เป็นเส้นตรงเรียบ (Linear) |
| การเปลี่ยน Commit ID | คงเดิม ไม่มีการแก้ไข Commit เก่า | สร้าง Commit ID ใหม่ขึ้นมาแทน |
| ความง่ายในการแก้ Conflict | แก้ Conflict ทีเดียวจบใน Merge Commit | อาจต้องแก้ Conflict ทีละ Commit ที่ Rebase |
| ความปลอดภัย | สูง เหมาะกับมือใหม่ | ต้องระวัง ไม่ควรทำกับ Public Branch |
สรุป: ควรเลือกใช้แบบไหนดี?
กฎเหล็กของ Rebase (The Golden Rule of Rebase): “ห้าม Rebase บน Branch ที่เป็น Public หรือแชร์ร่วมกับผู้อื่นเด็ดขาด!”
เลือกใช้ Rebase เมื่อ
- ทำงานบน Feature Branch ของตัวเองคนเดียว: ต้องการดึงโค้ดล่าสุดจาก
mainมาอัปเดตลง branch ตัวเอง เพื่อให้ประวัติคลีนๆ ก่อนส่ง Pull Request - อยากให้ History ของโปรเจกต์เป็นเส้นตรง: อ่านง่าย ตรวจสอบง่าย
เลือกใช้ Merge เมื่อ
- กำลังจะรวม Feature เข้าสู่ Branch หลัก (
main/develop): การเกิด Merge Commit ตรงจุดนี้เป็นเรื่องดี เพราะมันคือจุดบันทึกประวัติศาสตร์ว่า Feature นั้นๆ ถูกนำเข้าสู่ระบบเมื่อใด - ทำงานบน Branch เดียวกันหลายคน: ป้องกันไม่ให้ Commit ID เปลี่ยนจนเพื่อนร่วมทีมงง
อ่านเพิ่มเติม