Merge Conflict & Rebase
แก้เมื่อสองคนแก้บรรทัดเดียวกัน และเข้าใจว่า rebase ต่างจาก merge อย่างไร
เมื่อทำงานเป็นทีม จะมีบางครั้งที่สองคนแก้ไฟล์เดียวกันบรรทัดเดียวกัน git รวมเองไม่ได้ เกิด merge conflict — มันไม่น่ากลัว แค่ต้องบอก git ว่าจะเอาเวอร์ชันไหน หัวข้อนี้สอนวิธีแก้และความต่างของ rebase
conflict เกิดและหน้าตาเป็นอย่างไร
เมื่อ merge แล้วชนกัน git จะใส่เครื่องหมายในไฟล์บอกว่าส่วนไหนชน: ของเรา (HEAD) กับของอีกฝั่ง
<<<<<<< HEAD
price = 100 # โค้ดฝั่งเรา (branch ปัจจุบัน)
=======
price = 120 # โค้ดฝั่งที่กำลัง merge เข้ามา
>>>>>>> feature-xวิธีแก้ conflict
- เปิดไฟล์ที่ conflict (git status บอกว่าไฟล์ไหน)
- เลือกว่าจะเอาเวอร์ชันไหน หรือรวมมือ แล้วลบเครื่องหมาย <<<<, ====, >>>> ออก
- git add ไฟล์ที่แก้แล้ว
- git commit เพื่อจบการ merge
git merge feature-x
# CONFLICT (content): Merge conflict in app.py
# ...แก้ไฟล์ให้เหลือเวอร์ชันที่ต้องการ ลบ marker...
git add app.py
git commit # จบ mergemerge vs rebase
ทั้งคู่รวมงานจากอีก branch แต่ผลต่างกัน: merge สร้าง merge commit รวมสองสาย ส่วน rebase ย้าย commit ของเราไปต่อท้ายอีก branch ทำให้ประวัติเป็นเส้นตรงสวยงาม
| merge | rebase | |
|---|---|---|
| ประวัติ | แตกสาย + merge commit | เส้นตรง สะอาด |
| commit เดิม | คงไว้ | ถูกเขียนใหม่ (hash เปลี่ยน) |
| เหมาะกับ | รวมงานเข้า main | เก็บ branch ส่วนตัวให้สะอาดก่อน merge |
git switch feature-x
git rebase main # ย้าย commit ของ feature ไปต่อท้าย main ล่าสุดอย่า rebase branch ที่ push ขึ้น remote แล้วหรือที่คนอื่นใช้อยู่ เพราะ rebase เขียนประวัติใหม่ (hash เปลี่ยน) จะทำให้ของคนอื่นพัง — ใช้ rebase กับ branch ส่วนตัวที่ยังไม่ได้แชร์เท่านั้น
สรุปหัวข้อนี้
- conflict เกิดเมื่อแก้บรรทัดเดียวกันคนละทาง — git ใส่ marker <<< === >>>
- แก้: เลือกเวอร์ชัน ลบ marker → git add → git commit
- merge เก็บประวัติแตกสาย; rebase ทำประวัติเป็นเส้นตรง (เขียน commit ใหม่)
- ห้าม rebase ของที่ push/แชร์แล้ว
1) สร้าง conflict โดยแก้บรรทัดเดียวกันใน 2 branch แล้ว merge 2) แก้ conflict ให้จบ (เลือกเวอร์ชัน, add, commit) 3) ลอง rebase branch ส่วนตัวเข้า main 4) อธิบายว่าทำไมห้าม rebase ของที่แชร์แล้ว