Merge (การรวม) — คืออะไร, merge ทำงานอย่างไรและกลยุทธ์การรวม

Merge ใน Git คืออะไร

Merge คือคำสั่ง git merge ที่รวมการเปลี่ยนแปลงจากสาขาที่ระบุไปยังสาขาปัจจุบัน Git ค้นหาบรรพบุรุษร่วม (commit ฐาน) คำนวณ diff ของแต่ละสาขาเทียบกับบรรพบุรุษ และสร้าง commit การรวมที่มีชุดการเปลี่ยนแปลงที่รวมกัน ผลลัพธ์คือสาขาปลายทางได้รับการเปลี่ยนแปลงทั้งหมดจากสาขาที่ถูกรวม

ไวยากรณ์: ขณะอยู่ที่สาขาปลายทาง (เช่น main) ให้รัน git merge feature Git จะสร้าง commit การรวมโดยอัตโนมัติหากไม่มีข้อขัดแย้ง ข้อความ commit การรวมเริ่มต้นคือ: “Merge branch 'feature' into main” คุณสามารถเปลี่ยนข้อความได้โดยใช้แฟล็ก -m หรือแก้ไขในโปรแกรมแก้ไขที่เปิดขึ้น

Merge เป็นการดำเนินการที่ไม่ทำลาย ซึ่งแตกต่างจาก rebase, merge ไม่แตะต้อง commit ที่มีอยู่: พวกมันยังคงมี hash, ผู้เขียน และวันที่เหมือนเดิม ซึ่งทำให้ merge เป็นวิธีเดียวที่ปลอดภัยในการรวมสาขาที่นักพัฒนาหลายคนทำงานพร้อมกัน หากมีสิ่งผิดปกติ สามารถยกเลิก merge ได้ด้วย git merge --abort

# สลับไปยังสาขาปลายทาง
git checkout main

# รวมสาขาคุณสมบัติ
git merge feature

# ผลลัพธ์ — commit การรวมที่มี parent สองตัว
git log --oneline --graph

# รวมด้วยข้อความที่กำหนดเอง
git merge feature -m "feat: integrate authentication module"

ประเภทของ merge: regular, squash, fast-forward

Git รองรับสามโหมดการรวม ซึ่งเลือกตามผลลัพธ์ที่ต้องการ การรวมแบบปกติ (ค่าเริ่มต้น) สร้าง commit การรวม Squash merge รวม commit ทั้งหมดของสาขาคุณสมบัติเป็นหนึ่งเดียว Fast-forward เลื่อนตัวชี้สาขาไปข้างหน้าโดยไม่สร้าง commit หากเป็นไปได้ การเลือกโหมดขึ้นอยู่กับขั้นตอนการทำงานของทีมและกฎของประวัติ

การรวมแบบปกติ (--no-ff) — สร้าง commit การรวมแม้ว่าการรวมจะสามารถทำเป็น fast-forward ได้ แนะนำสำหรับสาขา main: commit การรวมจะระบุจุดรวมคุณสมบัติอย่างชัดเจนและช่วยให้ย้อนกลับการเปลี่ยนแปลงทั้งหมดของสาขาคุณสมบัติได้ง่ายด้วยการ revert เพียงครั้งเดียว GitHub ใช้โหมดนี้เป็นค่าเริ่มต้นเมื่อรวม PR ผ่านปุ่ม Merge

Squash merge (--squash) — รวบรวม commit ทั้งหมดของสาขาคุณสมบัติเป็น commit เดียวในสาขาปลายทาง มีประโยชน์เมื่อประวัติร่างของสาขาคุณสมบัติไม่ควรทำให้ main ยุ่งเหยิง ข้อเสีย: การเชื่อมต่อกับ commit ดั้งเดิมหายไป — ไม่สามารถเห็นว่าคุณสมบัติถูกพัฒนาทีละขั้นตอนอย่างไร GitHub ใช้โหมดนี้เมื่อเลือก “Squash and merge” ใน PR

Fast-forward (--ff) — หากสาขาปลายทางไม่มี commit ใหม่ตั้งแต่สาขาคุณสมบัติแตกออกไป Git ก็เพียงเลื่อนตัวชี้ไปข้างหน้าโดยไม่สร้าง commit การรวม ประวัติยังคงเป็นเส้นตรง แฟล็ก --no-ff บังคับให้สร้าง commit การรวม ในขณะที่ --ff-only จะแสดงข้อผิดพลาดหาก fast-forward ไม่สามารถทำได้

# บังคับ commit การรวม (แนะนำสำหรับ main)
git merge --no-ff feature

# Squash merge — commit ทั้งหมดเป็นหนึ่งเดียว
git merge --squash feature
git commit -m "feat: add authentication"

# Fast-forward เฉพาะเมื่อเป็นไปได้
git merge --ff-only feature

# ยกเลิกการรวมที่มีข้อขัดแย้ง
git merge --abort

กลยุทธ์การรวมของ Git

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

Recursive — กลยุทธ์เริ่มต้นสำหรับการรวมสองสาขา Git ค้นหาบรรพบุรุษร่วม คำนวณการเปลี่ยนแปลงในแต่ละสาขา และรวมเข้าด้วยกัน หากพบบรรพบุรุษร่วม recursive จะจัดการกับการเปลี่ยนชื่อไฟล์และการเพิ่มไฟล์อย่างถูกต้อง ระหว่างข้อขัดแย้ง recursive สามารถใช้ตัวเลือกเพิ่มเติม: ours (เลือกเวอร์ชันของเราโดยอัตโนมัติ) และ theirs (เลือกเวอร์ชันของพวกเขา)

Octopus — สำหรับการรวมมากกว่าสองสาขาพร้อมกัน: git merge feature1 feature2 feature3 Octopus ไม่รองรับการแก้ไขข้อขัดแย้ง — ข้อขัดแย้งทั้งหมดต้องได้รับการแก้ไขก่อนเรียกใช้คำสั่ง ใช้น้อยมาก ส่วนใหญ่เพื่อรวมสาขาอิสระหลายสาขาที่รับประกันว่าไม่ขัดแย้งกัน (เช่น โมดูลที่แตกต่างกัน)

Ours — กลยุทธ์พิเศษที่ไม่สนใจการเปลี่ยนแปลงจากสาขาที่ถูกรวมอย่างสิ้นเชิงและเก็บเนื้อหาปัจจุบันของสาขาปลายทางไว้ มีการสร้าง commit การรวมขึ้น แต่เนื้อหาไม่เปลี่ยนแปลง มีประโยชน์เมื่อคุณต้องการบันทึกข้อเท็จจริงของการรวมในประวัติแต่จริงๆ แล้วปฏิเสธการเปลี่ยนแปลงทั้งหมดจากสาขาอื่น

การแก้ไขข้อขัดแย้งของ merge

ข้อขัดแย้งของ merge เกิดขึ้นเมื่อบรรทัดเดียวกันของไฟล์ถูกเปลี่ยนแปลงต่างกันในทั้งสองสาขา Git ไม่สามารถระบุได้โดยอัตโนมัติว่าเวอร์ชันใดถูกต้องและหยุดการรวมชั่วคราว ข้อขัดแย้งอาจเกิดขึ้นเมื่อไฟล์ถูกเปลี่ยนชื่อในสาขาหนึ่งและถูกแก้ไขในอีกสาขาหนึ่ง หรือเมื่อไฟล์เดียวกันถูกลบและแก้ไขพร้อมกัน

กระบวนการแก้ไข: Git ทำเครื่องหมายไฟล์ที่มีข้อขัดแย้งด้วยเครื่องหมาย ไฟล์จะแสดงส่วนที่มี <<<<<<< HEAD (เวอร์ชันของเรา), ======= (ตัวคั่น) และ >>>>>>> feature (เวอร์ชันของพวกเขา) นักพัฒนาแก้ไขส่วนที่มีข้อขัดแย้งด้วยตนเอง เลือกบรรทัดที่ต้องการจากทั้งสองเวอร์ชัน ลบเครื่องหมาย บันทึกไฟล์ และเพิ่มลงในดัชนีด้วย git add

สำหรับการแก้ไขข้อขัดแย้งด้วยภาพ Git รองรับ mergetool — เครื่องมือเปรียบเทียบภายนอก Mergetool ยอดนิยม: Meld, KDiff3, Beyond Compare, VS Code (โปรแกรมแก้ไขข้อขัดแย้งในตัว) Mergetool แสดงสามแผง: เวอร์ชันของเรา เวอร์ชันของพวกเขา และผลลัพธ์ นักพัฒนาเลือกบล็อกโค้ดด้วยภาพเพื่อรวมในไฟล์สุดท้าย

# เริ่มการรวมและตรวจจับข้อขัดแย้ง
git merge feature
# ข้อขัดแย้ง (เนื้อหา): ข้อขัดแย้งการรวมใน src/main.swift

# ตรวจสอบไฟล์ที่มีข้อขัดแย้ง
git status

# เปิด mergetool แบบภาพ
git mergetool

# หลังการแก้ไข — add และ commit
git add src/main.swift
git commit

# ยกเลิกการรวม
git merge --abort

เมื่อใดควรเลือก merge แทน rebase

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

สถานการณ์ที่สอง: เมื่อเสร็จสิ้นสาขาคุณสมบัติ ทีมส่วนใหญ่ชอบ merge (ด้วยแฟล็ก --no-ff) ไปยัง main เพื่อบันทึกช่วงเวลาการรวมคุณสมบัติ ซึ่งช่วยให้การนำทางประวัติง่ายขึ้นและช่วยให้ย้อนกลับคุณสมบัติทั้งหมดได้ง่ายด้วย git revert เพียงครั้งเดียวของ commit การรวม GitHub Flow โดยค่าเริ่มต้นเสนอสามตัวเลือก merge: merge แบบง่าย, squash merge และ rebase merge

สถานการณ์ที่สาม: เมื่อทำงานกับ pull request ที่ผ่านการตรวจสอบแล้ว GitHub และ GitLab เสนอปุ่ม merge พร้อมตัวเลือกต่าง ๆ Merge (Create a merge commit) — ประวัติเต็มพร้อม commit การรวม Squash and merge — ประวัติที่สะอาดไม่มีรายละเอียดการพัฒนา Rebase and merge — ประวัติเชิงเส้นโดยไม่มี commit การรวม แต่มีการเขียน commit ใหม่ การเลือกขึ้นอยู่กับกฎของทีม

• สาขาสาธารณะ (main, develop) — merge เท่านั้น ไม่เคย rebase
• การเสร็จสิ้น PR — merge ด้วย --no-ff เพื่อระบุจุดรวม
• สาขาที่มี commit ของผู้อื่น — merge ไม่เขียนงานของผู้อื่นซ้ำ
• ก่อนเผยแพร่ — merge ปลอดภัยกว่าเนื่องจากมีความเสี่ยงน้อยกว่า
• สาขาที่ใช้ร่วมกัน — หากนักพัฒนาหลายคนทำงานบนสาขาเดียว merge เป็นสิ่งจำเป็น

แนวปฏิบัติที่ดีที่สุดสำหรับการรวมสาขา

กฎข้อแรก: ควรอยู่ในเวอร์ชันล่าสุดของสาขาปลายทางเสมอก่อนการรวม รัน git checkout main && git pull ก่อนรวมสาขาคุณสมบัติ ซึ่งช่วยลดข้อขัดแย้งและรับประกันว่า commit การรวมมีการเปลี่ยนแปลงล่าสุดทั้งหมด หากสาขาปลายทางก้าวหน้าไปมาก ให้รัน git merge main ภายในสาขาคุณสมบัติก่อนเพื่อแก้ไขข้อขัดแย้งในบริบทของมัน

กฎข้อที่สอง: ทดสอบโค้ดหลังจากการรวม การรวมสามารถเปลี่ยนพฤติกรรมได้แม้ไม่มีข้อขัดแย้ง CI/CD pipeline ควรรันทดสอบบน commit การรวมก่อนส่งไปยังโปรดักชัน บางทีมใช้ merge gates — การตรวจสอบบังคับที่ปิดกั้นการรวมจนกว่าจะผ่าน

กฎข้อที่สาม: จัดทำเอกสาร commit การรวม ข้อความมาตรฐาน “Merge branch 'feature' into main” มีประโยชน์ไม่มากนัก แนะนำให้เพิ่มคำอธิบายเกี่ยวกับสิ่งที่ถูกรวม: “Merge authentication module: login, registration, password recovery” ซึ่งช่วยให้การวิเคราะห์ประวัติและการค้นหาถดถอยง่ายขึ้น ในโครงการขนาดใหญ่ commit การรวมจะถูกสร้างโดยอัตโนมัติจากชื่อ PR

• ความทันสมัย — ก่อนการรวม ตรวจสอบให้แน่ใจว่าสาขาปลายทางอัปเดตแล้ว (git pull)
• การทดสอบ — CI/CD ควรรันทดสอบบน commit การรวมที่ได้
• ข้อความอธิบาย — ระบุใน commit การรวมว่าคุณสมบัติใดถูกรวม
• ความถี่ — รวมสาขาคุณสมบัติให้เร็วและบ่อยเท่าที่เป็นไปได้ (สูงสุดหนึ่งสัปดาห์)
• การย้อนกลับ — git revert ของ commit การรวมจะย้อนกลับคุณสมบัติทั้งหมด