ความแตกต่างระหว่าง rebase และ merge คืออะไร?

Question

Accepted Answer

ทั้ง **merge** และ **rebase** ผสานการเปลี่ยนแปลงจาก branch หนึ่งเข้ากับอีก branch หนึ่ง แต่ทำต่างกัน: merge **รักษาประวัติ** ด้วย merge commit ในขณะที่ rebase **เขียนประวัติใหม่** เพื่อสร้างลำดับแบบเส้นตรง การเข้าใจความแตกต่างและเมื่อใดควรใช้แต่ละอย่างเป็นสิ่งสำคัญ

## Merge — รักษาประวัติ (รวมเข้าด้วยกัน)

```text
main:     A───B───C───────M     ← M is a MERGE COMMIT (two parents)
                  \       /
feature:           D───E
→ git merge feature: creates M combining the branches
  ✓ Preserves the actual history (shows the branch existed, when it merged)
  ✗ History has merge commits (can look cluttered with many merges)
```

## Rebase — เขียนใหม่เพื่อประวัติแบบเส้นตรง (เล่นซ้ำ)

```text
BEFORE:  main: A───B───C    feature: A───B───D───E
AFTER rebase feature onto main:
         main: A───B───C    feature: A───B───C───D'───E'
→ git rebase main (on feature): REPLAYS feature's commits (D,E) ON TOP of main's latest (C)
  ✓ LINEAR, clean history (no merge commits) — as if feature was built on current main
  ✗ REWRITES commits (D→D', E→E' are NEW commits with new hashes)
```

Rebase **ย้าย** commit ของ branch ของคุณไปเริ่มต้นจากปลายของอีก branch หนึ่ง สร้าง commit ใหม่ — สร้างประวัติที่สะอาดและเป็นเส้นตรง

## กฎทองของการ rebase

```text
⚠️ NEVER rebase commits that have been PUSHED/SHARED (public history):
  → rebasing rewrites commits (new hashes) → diverges from what others have
  → causes serious confusion and conflicts for collaborators
→ Rebase only LOCAL, unpushed commits. Merge for integrating shared/public branches.
```

## เมื่อใดควรใช้แต่ละอย่าง

```text
MERGE  → integrating shared branches; preserving true history; team default for merging
  features to main (often via pull requests). Safe, non-destructive.
REBASE → cleaning up LOCAL commits before sharing; keeping a feature branch up-to-date
  with main (linear); achieving clean linear history. On local/private commits only.
→ Common workflow: rebase locally to tidy up, then merge (or PR) into main.
```

## ทำไมจึงสำคัญ

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

ความแตกต่างหลัก — **merge รักษาประวัติ** (สร้าง merge commit ที่บันทึกว่า branch ถูกรวมเข้าด้วยกัน รักษาประวัติการพัฒนาที่แท้จริงไว้) ในขณะที่ **rebase เขียนประวัติใหม่** (เล่นซ้ำ commit ลงบนปลายของอีก branch หนึ่งเพื่อสร้างลำดับที่สะอาดและเป็นเส้นตรงราวกับว่างานถูกทำบนโค้ดล่าสุด) — ส่งผลต่อหน้าตาและการอ่านของประวัติโปรเจกต์

การเข้าใจ trade-off (merge: ถูกต้องแต่อาจรกด้วย merge commit; rebase: สะอาดและเป็นเส้นตรงแต่เขียน commit ใหม่) ช่วยเลือกตามว่าคุณให้คุณค่ากับประวัติที่แท้จริงหรือความสะอาดแบบเส้นตรง

ที่สำคัญที่สุด การเข้าใจ **กฎทองของการ rebase** — **อย่า rebase commit ที่ถูก push/แชร์แล้ว** — เป็นสิ่งจำเป็นเพราะการ rebase เขียน commit ใหม่ (ให้ hash ใหม่) ดังนั้นการ rebase ประวัติที่ใช้ร่วมกันจะแตกต่างจากที่ผู้ร่วมงานมี ก่อให้เกิดความสับสนและ conflict ที่ร้ายแรง; rebase ปลอดภัยเฉพาะกับ commit ในเครื่องที่ยังไม่ push เท่านั้น

กฎความปลอดภัยนี้สำคัญยิ่งและเป็นแหล่งปัญหาที่พบบ่อยเมื่อถูกละเมิด

การเข้าใจ **เมื่อใดควรใช้แต่ละอย่าง** (merge สำหรับการผสาน branch ที่ใช้ร่วมกันและรักษาประวัติ มักเป็นค่าเริ่มต้นของทีมในการ merge feature ผ่าน pull request; rebase สำหรับการเก็บกวาด commit ในเครื่องก่อนแชร์หรือการรักษา feature branch ให้ทันสมัยแบบเส้นตรง — เฉพาะกับ commit ในเครื่องเท่านั้น) สะท้อนถึงการใช้ Git ที่ดี

เนื่องจากการผสานการเปลี่ยนแปลงเป็นพื้นฐานและตัวเลือก merge เทียบกับ rebase (พร้อมนัยด้านประวัติและความปลอดภัย) เป็นการตัดสินใจที่พบบ่อยและเป็นหัวข้อสัมภาษณ์ การเข้าใจความแตกต่าง — ผลต่อประวัติ กฎทองที่สำคัญ และเมื่อใดควรใช้แต่ละอย่าง — จึงเป็นความรู้ Git ที่มีค่าและสำคัญเชิงปฏิบัติซึ่งเป็นแกนกลางของการรักษาประวัติที่สะอาดอย่างปลอดภัย และเป็นความแตกต่างที่ถูกพูดถึงบ่อยที่นักพัฒนาทุกคนควรเข้าใจ