Rebase: คืออะไร แตกต่างจาก Merge อย่างไร และหลักการทำงาน

Rebase คืออะไร?

Rebase (การรีเบส) คือการดำเนินการใน Git ที่ย้ายคอมมิตจากสาขาปัจจุบันไปยังจุดฐานใหม่ แทนที่จะสร้างคอมมิตการรวม rebase จะนำแต่ละคอมมิตจากสาขาต้นทางมาใช้ทีละตัวบนฐานใหม่ ผลลัพธ์คือลำดับคอมมิตเชิงเส้นที่ไม่มีการแตกสาขา

ชื่อ rebase มาจาก “re-base” — การเปลี่ยนฐาน ในขณะที่ merge รวมสองสาขาที่จุดเดียว rebase จะย้ายสาขาทั้งหมดของคุณไปยังตำแหน่งใหม่ ทำให้ดูเหมือนว่าคุณเริ่มพัฒนาจากสถานะปัจจุบันของสาขาปลายทาง สิ่งนี้สร้างภาพลวงตาของงานที่เรียงลำดับอย่างสมบูรณ์แบบ

ตามข้อมูลของ Atlassian, 2025 ทีมที่ใช้ rebase สำหรับสาขาคุณสมบัติใช้เวลาในการวิเคราะห์ประวัติคอมมิตน้อยกว่า 30% เมื่อเทียบกับทีมที่ใช้ merge เพียงอย่างเดียว ประวัติเชิงเส้นทำให้ git blame, bisect และการดู log ผ่าน git log --oneline ง่ายขึ้น

ความแตกต่างพื้นฐานจาก Merge

Merge รวมสาขาโดยการสร้างคอมมิตที่มีพ่อแม่สองคน Rebase เขียนประวัติใหม่: คอมมิตใหม่ถูกสร้างขึ้นด้วยแฮชใหม่ แม้ว่าการเปลี่ยนแปลงจะเหมือนกับต้นฉบับ ซึ่งหมายความว่า rebase เปลี่ยนตัวระบุ SHA ของคอมมิต ซึ่งสำคัญสำหรับสาขาสาธารณะ

Rebase ทำงานอย่างไร

กลไกของ rebase ประกอบด้วยสี่ขั้นตอน: Git หาบรรพบุรุษร่วม (merge base) ของสาขาปัจจุบันและสาขาปลายทาง จากนั้นใช้คอมมิตแต่ละตัวของสาขาปัจจุบันบนสาขาปลายทางตามลำดับ หากเกิดข้อขัดแย้งในขั้นตอนใด rebase จะหยุดและรอการแก้ไข

# สถานการณ์เริ่มต้น: สาขา feature ตามหลัง develop อยู่ 3 คอมมิต
git checkout feature/new-login
git rebase develop

# Git นำ 3 คอมมิตจาก feature และใช้บน develop
# หากไม่มีข้อขัดแย้ง — rebase จะเสร็จสมบูรณ์โดยอัตโนมัติ
# หากมี — Git จะหยุดที่คอมมิตที่มีข้อขัดแย้ง

หลังจาก rebase สาขาคุณสมบัติ จะมีคอมมิตทั้งหมดจาก develop บวกกับคอมมิตของตัวเอง ซึ่งปรากฏเป็นส่วนต่อเนื่องของ develop ซึ่งช่วยให้รวมเข้า develop ผ่าน fast-forward โดยไม่ต้องสร้างคอมมิตการรวม

กระบวนการทีละขั้นตอน

ลองดูตัวอย่างโดยละเอียด: นักพัฒนาสร้างสาขาคุณสมบัติจาก develop ทำสองคอมมิต ในขณะที่นักพัฒนาคนอื่นเพิ่มสามคอมมิตใน develop Rebase จะย้ายสองคอมมิตของคุณสมบัติไปยังตำแหน่งใหม่ สร้างสำเนาด้วย SHA ใหม่

# 1. สร้างสาขา feature
git checkout -b feature/payment-refactor develop

# 2. ทำคอมมิตใน feature
git commit -m "refactor: extract payment validation"
git commit -m "refactor: add payment gateway interface"

# 3. อัปเดต develop (งานของเพื่อนร่วมทีม)
git checkout develop
git pull

# 4. Rebase feature บน develop ใหม่
git checkout feature/payment-refactor
git rebase develop

# 5. ตอนนี้ feature สามารถรวมผ่าน fast-forward
git checkout develop
git merge feature/payment-refactor

หากเกิดข้อขัดแย้งในขั้นตอนที่ 4 Git จะหยุดที่คอมมิตที่มีปัญหา นักพัฒนาแก้ไขข้อขัดแย้ง รัน git add และดำเนินการ git rebase --continue เพื่อข้ามคอมมิต — git rebase --skip เพื่อยกเลิก rebase ทั้งหมด — git rebase --abort

การข้ามคอมมิตว่างโดยอัตโนมัติ

แฟล็ก --empty ควบคุมพฤติกรรมของ rebase กับคอมมิตว่าง — สถานการณ์ที่การเปลี่ยนแปลงทั้งหมดของคอมมิตอยู่ในสาขาปลายทางแล้ว โดยค่าเริ่มต้น rebase จะหยุดและขอการตัดสินใจ ด้วย --empty=drop Git จะข้ามคอมมิตเหล่านั้นโดยอัตโนมัติโดยไม่หยุด ซึ่งช่วยเร่งการรีเบสจำนวนมากที่มีคอมมิตจำนวนมาก

Rebase แบบโต้ตอบ

Rebase แบบโต้ตอบ (git rebase -i) เป็นเครื่องมือที่มีประสิทธิภาพสำหรับการแก้ไขประวัติคอมมิต มันเปิดโปรแกรมแก้ไขพร้อมรายการคอมมิตและคำสั่งสำคัญ: pick (เก็บไว้), reword (เปลี่ยนข้อความ), edit (เปลี่ยนเนื้อหา), squash (รวมกับคอมมิตก่อนหน้า), fixup (รวมโดยไม่ต้องมีข้อความ), drop (ลบ)

# Rebase แบบโต้ตอบของ 4 คอมมิตล่าสุด
git rebase -i HEAD~4

# โปรแกรมแก้ไขจะเปิดพร้อมแผน rebase:
# pick a1b2c3 feat: add login screen
# pick d4e5f6 fix: login validation
# pick g7h8i9 fix: login layout
# pick j0k1l2 docs: add login comments

# เปลี่ยนเป็น:
# pick a1b2c3 feat: add login screen
# squash d4e5f6 fix: login validation
# squash g7h8i9 fix: login layout
# drop j0k1l2 docs: add login comments

ผลลัพธ์: สามคอมมิต (หน้าจอเข้าสู่ระบบ, การตรวจสอบ, เค้าโครง) ถูกบีบอัดเป็นหนึ่งเดียว และคอมมิตที่มีความคิดเห็นถูกลบ ซึ่งช่วยให้ส่งประวัติที่สะอาดสำหรับการตรวจสอบโค้ดโดยไม่มีร่างและการแก้ไข Rebase แบบโต้ตอบเป็นเครื่องมือมาตรฐานสำหรับการเตรียมสาขาคุณสมบัติก่อน Pull Request

Rebase vs Merge: การเปรียบเทียบ

Rebase และ Merge แก้ปัญหาเดียวกัน — การรวมการเปลี่ยนแปลง — แต่ในวิธีที่แตกต่างกันโดยพื้นฐาน การเลือกระหว่างพวกมันขึ้นอยู่กับประเภทของประวัติที่คุณต้องการเห็นใน git log และใครอีกบ้างที่ทำงานกับสาขาของคุณ

กฎปฏิบัติ: ใช้ merge สำหรับการรวมเข้ากับสาขาที่ใช้ร่วมกัน (develop, main) และ rebase สำหรับการอัปเดตสาขาคุณสมบัติส่วนตัว หลายทีมรวมทั้งสองอย่าง: rebase คุณสมบัติบน develop จากนั้น --no-ff merge เข้า develop

ผลกระทบต่อ git bisect

Git bisect เป็นเครื่องมือสำหรับค้นหาคอมมิตที่ทำให้เกิดการถดถอย เมื่อใช้ merge git bisect จะผ่านคอมมิตการรวมอย่างถูกต้องโดยพิจารณาทั้งพ่อแม่สองคน ด้วย rebase bisect ทำงานเร็วขึ้นเพราะประวัติเป็นเชิงเส้นและไม่ต้องการการแตกสาขา อย่างไรก็ตาม หาก rebase เกิดขึ้นหลังจากที่คอมมิตเป็นที่รู้จักของทีม SHA ดั้งเดิมจะหายไปและ bisect อาจไม่พบคอมมิตที่มีปัญหา

เมื่อใดควรใช้ Rebase

Rebase เหมาะที่สุดในสามสถานการณ์: การเตรียมสาขาคุณสมบัติสำหรับ Pull Request การอัปเดตสาขาส่วนตัวให้เป็นสถานะปัจจุบันของ main/develop และการทำความสะอาดประวัติก่อนการรวม ในแต่ละกรณี rebase ช่วยเพิ่มความอ่านได้ของประวัติโดยไม่มีความเสี่ยงต่อการทำงานเป็นทีม

ก่อนPull Request แนะนำให้ทำ rebase แบบโต้ตอบเพื่อรวมคอมมิตแบบร่าง (WIP, การแก้ไขหลังการตรวจสอบ) เป็นหน่วยตรรกะที่มีความหมาย ซึ่งช่วยให้การตรวจสอบโค้ดง่ายขึ้น: ผู้ตรวจสอบเห็นไม่ใช่ 15 คอมมิตเล็ก ๆ แต่เป็นการเปลี่ยนแปลงที่มีโครงสร้าง 3-5 รายการพร้อมข้อความที่ชัดเจน

สำหรับการอัปเดตสาขาคุณสมบัติ rebase ดีกว่า merge เพราะมันไม่สร้างคอมมิตการรวมที่ไม่จำเป็น หากคุณรัน git rebase develop เป็นระยะภายในสาขาคุณสมบัติ การรวมสุดท้ายจะไม่มีคอมมิตการรวม 10 ตัว — มีเพียงคอมมิตคุณสมบัติที่สะอาดบน develop

การทำความสะอาดประวัติ ผ่าน rebase แบบโต้ตอบก่อนการรวมช่วยให้ซ่อนการแก้ไขเล็กน้อย (การพิมพ์ผิด, การจัดรูปแบบ) และจัดกลุ่มคอมมิตตามฟังก์ชันการทำงาน ข้อความ Git ควรปฏิบัติตามข้อตกลง Conventional Commits (fix:, feat:, refactor:, docs:) ซึ่งสร้าง changelog อัตโนมัติ

ความเสี่ยงและกฎของ Rebase

Rebase เป็นการดำเนินการที่อันตรายหากใช้ผิดวิธี ความเสี่ยงหลักคือการเขียนประวัติที่เผยแพร่แล้วซ้ำ หากนักพัฒนา rebase สาขาที่คนอื่น push ไว้แล้วและกำลังใช้อยู่ สำเนาท้องถิ่นของพวกเขาจะไม่ตรงกันและพวกเขาจะต้องทำ force-pull ด้วยความเสี่ยงที่จะสูญเสียข้อมูล

• กฎทอง: อย่า rebase คอมมิตที่มีอยู่ในที่เก็บร่วมกันแล้ว สิ่งนี้ใช้กับสาขาใด ๆ ที่สมาชิกทีมคนอื่นสามารถเข้าถึงได้
• Force push: หลังจาก rebase สาขาคุณสมบัติท้องถิ่น จำเป็นต้อง push ด้วยแฟล็ก --force-with-lease ซึ่งปลอดภัยกว่า --force เพราะตรวจสอบว่ามีคนอื่นอัปเดตสาขาบนเซิร์ฟเวอร์หรือไม่
• การสูญเสียบริบท: rebase ทำลายข้อมูลเกี่ยวกับเวลาที่สาขาคุณสมบัติถูกสร้างและจากสาขาใด หากการเก็บวันที่สร้างสาขาเป็นสิ่งสำคัญ ให้ใช้ merge
• ข้อขัดแย้ง: ระหว่าง rebase ต้องแก้ไขข้อขัดแย้งสำหรับแต่ละคอมมิตแยกกัน ซึ่งอาจน่าเบื่อเมื่อมีคอมมิตจำนวนมาก

เพื่อลดความเสี่ยง ให้ปฏิบัติตามกฎนี้: rebase เฉพาะสาขาส่วนตัวที่ยังไม่ได้เผยแพร่ หากสาขาอยู่ในที่เก็บร่วมกันแล้ว ให้ใช้ merge กับ --no-ff หากคุณต้องการ rebase สาขาที่เผยแพร่แล้ว ให้แจ้งทีมและประสานงาน force push ล่วงหน้า

การป้องกันอัตโนมัติ ต่อ rebase ที่อันตรายถูกนำไปใช้ผ่าน hooks ฝั่งเซิร์ฟเวอร์: pre-receive hook บนเซิร์ฟเวอร์ Git สามารถตรวจสอบว่า push เขียนคอมมิตที่เผยแพร่แล้วซ้ำหรือไม่ GitHub และ GitLab มีการป้องกันในตัวสำหรับสาขาที่ได้รับการป้องกัน — force push จะถูกบล็อกจนกว่าผู้ดูแลระบบจะยกเลิกการป้องกัน