Merge Request (MR): คืออะไร วิธีสร้าง และกระบวนการตรวจสอบ

Merge Request (MR) คืออะไร?

Merge Request (MR) — คำขอรวมการเปลี่ยนแปลงจากสาขา Git หนึ่งไปยังอีกสาขาหนึ่ง ซึ่งเริ่มกระบวนการตรวจสอบโค้ดและการตรวจสอบอัตโนมัติ ต่างจากการรวมโดยตรงผ่านคอนโซล MR สร้างขั้นตอนที่เป็นทางการ: นักพัฒนาอธิบายการเปลี่ยนแปลง กำหนดผู้ตรวจสอบ เริ่ม CI/CD และรับข้อเสนอแนะก่อนที่จะใช้การเปลี่ยนแปลง นี่คือองค์ประกอบสำคัญของ GitLab แต่กลไกที่เทียบเท่าใน GitHub เรียกว่า Pull Request (PR)

ตาม GitLab Documentation, 2026 มีการสร้าง Merge Requests มากกว่า 80 ล้านรายการใน GitLab ต่อปี MR แต่ละรายการประกอบด้วยสี่องค์ประกอบหลัก: คำอธิบายพร้อมบริบทการเปลี่ยนแปลง รายการ commits ความแตกต่างของโค้ด (diff) และการหารือ (เธรดการหารือ) หากไม่มีองค์ประกอบใดองค์ประกอบหนึ่ง MR ถือว่าไม่สมบูรณ์

Merge Request (MR) แก้ปัญหาสามประการ: ป้องกันการเปลี่ยนแปลงโดยตรงในสาขาที่ได้รับการป้องกัน (main, develop) ให้การควบคุมคุณภาพผ่านการตรวจสอบ และเก็บรักษาประวัติการหารือสำหรับนักพัฒนาในอนาคต ใน GitLab สถานะ MR จะแสดงในอินเทอร์เฟซด้วยตัวบ่งชี้สี: เทาสำหรับ Draft, ส้มสำหรับรอดำเนินการ, เขียวสำหรับ Approved, ม่วงสำหรับ Merged และแดงสำหรับ Closed

คำศัพท์: MR, PR และ CR

ในแพลตฟอร์ม Git ที่แตกต่างกัน Merge Request ถูกเรียกต่างกัน GitLab ใช้ “Merge Request” (MR), GitHub ใช้ “Pull Request” (PR) การเปรียบเทียบคือ Change Request (CR) ใน Gerrit ทั้งสามหมายถึงกระบวนการเดียวกัน: คำขอรวมการเปลี่ยนแปลงผ่านการตรวจสอบโค้ด การเลือกคำศัพท์ขึ้นอยู่กับแพลตฟอร์มที่ใช้ในโปรเจกต์เท่านั้น

# สร้างสาขาที่มีการเปลี่ยนแปลง
git checkout -b feature/add-auth
git commit -m "Add OAuth2 authentication flow"
git push origin feature/add-auth

# คุณสามารถสร้าง MR ผ่านอินเทอร์เฟซ GitLab/GitHub หรือ CLI:
gh pr create --title "Add OAuth2 authentication flow" \
  --body "Implements OAuth2 with Google and Apple providers" \
  --reviewer "team-lead"

MR vs PR: ความแตกต่างระหว่าง GitLab และ GitHub

Merge Request ใน GitLab และ Pull Request ใน GitHub เป็นกลไกที่ทำงานเหมือนกันแต่มีชื่อต่างกัน ความแตกต่างเกิดจากประวัติศาสตร์: GitLab เริ่มต้นวางตำแหน่งตัวเองเป็นทางเลือกแบบโฮสต์เอง (Self-Hosted) สำหรับ GitHub และเลือกคำว่า “merge request” สำหรับกระบวนการรวม GitHub ซึ่งเปิดตัวก่อนหน้านี้ ใช้ “pull request” — คำขอให้ “ดึง” (pull) การเปลี่ยนแปลงเข้าสู่สาขาหลัก

ตาม GitHub Docs, 2024 ทั้งสองเครื่องมือรองรับชุดคุณสมบัติเดียวกัน: คำอธิบาย Markdown การกำหนดผู้ตรวจสอบ ความคิดเห็นในบรรทัดโค้ดเฉพาะ สถานะการตรวจสอบ และการรวมอัตโนมัติเมื่อตรงตามเงื่อนไข ความแตกต่างเกี่ยวข้องกับอินเทอร์เฟซและความสามารถเพิ่มเติม

วิธีสร้าง Merge Request: คำแนะนำทีละขั้นตอน

การสร้าง Merge Request (MR) เริ่มต้นด้วยการเผยแพร่สาขาที่มีการเปลี่ยนแปลงไปยังที่เก็บระยะไกล หลังจาก push ไปยัง GitLab หรือ GitHub อินเทอร์เฟซจะแสดงปุ่ม “Create Merge Request” หรือ “Compare & Pull Request” นักพัฒนากรอกคำอธิบาย ระบุสาขาเป้าหมาย (โดยปกติคือ develop หรือ main) กำหนดผู้ตรวจสอบ และแนบป้ายกำกับ

ตาม GitLab Documentation, 2025 MR มาตรฐานประกอบด้วยหัวข้อสูงสุด 72 ตัวอักษร คำอธิบายพร้อมเทมเพลต และลิงก์ไปยัง issue คำอธิบายควรตอบคำถาม: ทำอะไรไป ทำไม ทดสอบอย่างไร GitLab รองรับการปิด issue อัตโนมัติเมื่อรวมผ่านคำหลัก Closes, Fixes, Resolves

# ตัวอย่างเทมเพลต .gitlab/merge_request_templates/default.md
## What does this MR do?

[คำอธิบายสั้น ๆ เกี่ยวกับการเปลี่ยนแปลง: อะไรและทำไม]

## How to test

1. รัน ./gradlew test
2. ตรวจสอบ LoginActivity ด้วยโทเค็นทดสอบ
3. ตรวจสอบว่าไม่มีการถดถอยใน AuthManager

## Related issues

Closes #142

วงจรชีวิตของ MR: ตั้งแต่ Draft ถึง Merged

Merge Request (MR) ผ่านห้าสถานะใน GitLab สถานะแรกคือ Draft (ร่าง) ซึ่งมีคำนำหน้า “Draft:” ในหัวข้อและบล็อกการรวม เมื่อพร้อม นักพัฒนาจะลบ Draft และ MR จะเปลี่ยนเป็นสถานะ Opened — การตรวจสอบโค้ดเริ่มต้นและไปป์ไลน์ CI/CD เริ่มทำงาน

ตาม GitLab Docs, 2024 ในสถานะ Opened ผู้ตรวจสอบจะตรวจสอบ diff แสดงความคิดเห็น และขอการเปลี่ยนแปลงผ่าน Resolve Threads เมื่อเธรดทั้งหมดได้รับการแก้ไขและ CI/CD ผ่านสำเร็จ นักพัฒนาที่รับผิดชอบจะตั้งค่า Approve หลังจากนั้น MR สามารถรวมได้โดยใช้ปุ่ม Merge หรือรอการรวมอัตโนมัติ (Auto-merge)

GitLab รองรับสามตัวเลือกสถานะสุดท้าย: Merged (รวมสำเร็จ), Closed (ปิดโดยไม่รวม เช่น เมื่อยกเลิกฟีเจอร์) และ Reopened (เปิดอีกครั้งหลังปิด) แต่ละสถานะจะถูกบันทึกในไทม์ไลน์กิจกรรมของ MR เพื่อการตรวจสอบ

สถานะอัตโนมัติและทริกเกอร์

GitLab อัปเดตสถานะ Merge Request โดยอัตโนมัติเมื่อเกิดเหตุการณ์: การ push commits ใหม่จะรีเซ็ต Approvals เมื่อไปป์ไลน์ CI สำเร็จสถานะจะกลายเป็น Pipeline passed เมื่อล้มเหลว — Pipeline failed (การรวมถูกบล็อก) สามารถกำหนดค่า Auto-merge ได้: MR จะถูกรวมโดยอัตโนมัติหลังจาก CI สำเร็จและได้รับการอนุมัติตามที่กำหนดทั้งหมด

• Draft — ร่าง CI ทำงานแต่การรวมถูกบล็อก
• Opened — พร้อมตรวจสอบ กำหนดผู้ตรวจสอบแล้ว ไปป์ไลน์ทำงาน
• Approved — ได้รับจำนวนการอนุมัติตามต้องการแล้ว
• Merged — การเปลี่ยนแปลงถูกรวมในสาขาเป้าหมาย
• Closed — ปิดโดยไม่รวม

กฎการตรวจสอบโค้ดใน Merge Request

การตรวจสอบโค้ดใน Merge Request (MR) เป็นขั้นตอนบังคับในโครงการเชิงพาณิชย์ส่วนใหญ่ ตามการวิจัยของ SmartBear, 2023 การตรวจสอบโค้ดด้วย MR ช่วยลดจำนวนข้อบกพร่องลง 30–60% และเร่งการเริ่มงานของนักพัฒนาใหม่ กฎหลักคือ MR แต่ละรายการควรได้รับการตรวจสอบโดยนักพัฒนาอย่างน้อยหนึ่งคน โดยควรเป็นสองคนที่ไม่ได้มีส่วนร่วมในการเขียนโค้ด

การตรวจสอบ MR ประกอบด้วยห้าเกณฑ์: ความถูกต้องของตรรกะ การปฏิบัติตามรูปแบบโค้ด ความครอบคลุมของการทดสอบ ความปลอดภัย และประสิทธิภาพ ใน GitLab สามารถกำหนดค่า Required Approvals — จำนวนการอนุมัติที่บังคับก่อนรวม เช่น 2 การอนุมัติสำหรับ main และ 1 สำหรับ develop

การหารือใน MR ดำเนินการในเธรด — ความคิดเห็นในบรรทัดโค้ดเฉพาะ แต่ละเธรดต้องได้รับการแก้ไขก่อนรวม เพื่อเร่งการตรวจสอบ แนะนำให้จำกัดขนาด MR: 200–400 บรรทัดของการเปลี่ยนแปลง ตาม Google Research (2022) MR ที่มากกว่า 400 บรรทัดจะถูกตรวจสอบอย่างมีประสิทธิภาพน้อยลง 30%

ไปป์ไลน์ CI/CD ใน Merge Request

เมื่อสร้าง Merge Request (MR) ไปป์ไลน์ CI/CD จะเริ่มทำงานโดยอัตโนมัติ ใน GitLab สิ่งนี้เกิดขึ้นผ่านไฟล์ .gitlab-ci.yml ใน GitHub ผ่านเวิร์กโฟลว์ GitHub Actions ไปป์ไลน์รวมถึงการบิลด์โปรเจกต์ การทดสอบหน่วย linters การวิเคราะห์แบบคงที่ (SAST) และการตรวจสอบความครอบคลุมของโค้ด

ตาม GitLab Blog, 2024 สถานะไปป์ไลน์จะแสดงโดยตรงใน MR: เครื่องหมายถูกสีเขียว (passed), กากบาทสีแดง (failed) หรือวงกลมสีเหลือง (running) หากไปป์ไลน์ล้มเหลว GitLab จะบล็อกปุ่ม Merge จนกว่าจะแก้ไข ในการตั้งค่า สามารถเปิดใช้งาน “Merge when pipeline succeeds” — การรวมอัตโนมัติหลังจากไปป์ไลน์สำเร็จ

# .gitlab-ci.yml — ตัวอย่างสำหรับโปรเจกต์ Android
test:
  stage: test
  script:
    - ./gradlew ktlintCheck
    - ./gradlew testDebugUnitTest
  only:
    - merge_requests

build:
  stage: build
  script:
    - ./gradlew assembleDebug
  only:
    - merge_requests

วิธีการรวม: Squash, Merge Commit, Fast-Forward

GitLab และ GitHub เสนอสามวิธีการรวมสำหรับ Merge Request การเลือกขึ้นอยู่กับนโยบายของทีมและความสะอาดของประวัติที่ต้องการ Merge Commit สร้าง commit การรวมแยกต่างหาก โดยเก็บรักษาประวัติทั้งหมดของสาขาฟีเจอร์ Squash รวม commits ทั้งหมดของสาขาเป็น commit เดียวบนสาขาเป้าหมาย Fast-Forward ใช้ commits แบบเชิงเส้นโดยไม่มี commit การรวม

ตาม GitLab Docs, 2025 Squash เป็นที่นิยมสำหรับโปรเจกต์ที่มีความหนาแน่นของ commits สูง (20+ commits ในสาขาฟีเจอร์เดียว) Fast-Forward เป็นข้อบังคับสำหรับ Trunk-Based Development Merge Commit ใช้ใน Git Flow เพื่อรักษาความหมายของการแตกสาขา

• Merge Commit — เก็บรักษาประวัติ สร้าง commit การรวม เหมาะสำหรับ Git Flow
• Squash — รวม commits ทั้งหมดเป็นหนึ่งเดียว ประวัติสะอาด สูญเสีย commits กลาง
• Fast-Forward — ประวัติเชิงเส้นไม่มี commit การรวม ข้อบังคับใน TBD

แนวปฏิบัติที่ดีที่สุด: วิธีเขียน MR ที่ดี

Merge Request (MR) ที่มีคุณภาพ ช่วยลดเวลาในการตรวจสอบและจำนวนข้อผิดพลาด กฎข้อแรกคือ MR หนึ่งรายการแก้ไขงานหนึ่งงาน หากการเปลี่ยนแปลงส่งผลกระทบต่อหลายฟีเจอร์ที่ไม่เกี่ยวข้อง ควรแบ่งเป็น MR แยกต่างหาก ประการที่สอง หัวข้อ MR ควรให้ข้อมูล: “Add OAuth2 authentication with Google provider” แทน “Fix stuff” หรือ “Update code”

ตาม Google Engineering Practices, 2024 MR ที่ดีประกอบด้วยคำอธิบายบริบท: เหตุใดการเปลี่ยนแปลงจึงจำเป็น ทดสอบอย่างไร และมีความเสี่ยงอะไรบ้าง ขนาดของ MR ไม่ควรเกิน 400 บรรทัดของการเปลี่ยนแปลง หากปริมาณมากกว่า งานต้องถูกแบ่งย่อยเป็นงานย่อย สำหรับเอกสารประกอบและการทดสอบ ข้อยกเว้นสามารถยอมรับได้แต่ต้องมีคำอธิบาย

Merge Request (MR) ควรรวมการทดสอบอัตโนมัติสำหรับฟังก์ชันใหม่ ใน GitLab สามารถกำหนดค่านโยบาย Coverage Check — MR จะถูกบล็อกโดยอัตโนมัติหากความครอบคลุมของโค้ดต่ำกว่าเกณฑ์ (เช่น 80%) สิ่งนี้รับประกันว่าฟังก์ชันใหม่จะไม่ลดคุณภาพโดยรวมของโปรเจกต์

• หนึ่ง MR — หนึ่งงาน: แบ่งการเปลี่ยนแปลงใหญ่เป็น MR เล็กหลายรายการ
• คำอธิบายพร้อมเทมเพลต: ใช้ .gitlab/merge_request_templates เพื่อความสอดคล้อง
• ขนาดสูงสุด 400 บรรทัด: MR ใหญ่ถูกตรวจสอบช้ากว่าและมีข้อผิดพลาดมากกว่า
• การทดสอบบังคับ: ฟีเจอร์ใหม่ต้องครอบคลุมโดยการทดสอบหน่วย

เทมเพลตคำอธิบาย MR

GitLab รองรับเทมเพลต Merge Request ผ่านไฟล์ .gitlab/merge_request_templates/ เทมเพลตประกอบด้วยส่วนต่างๆ: สิ่งที่ทำ วิธีทดสอบ งานที่เกี่ยวข้อง และรายการตรวจสอบ การใช้เทมเพลตช่วยเร่งการสร้าง MR และรับประกันว่านักพัฒนาจะไม่ลืมรวมข้อมูลสำคัญ ในคำอธิบาย MR ต้องระบุ issues ที่เกี่ยวข้อง (Closes #N) สำหรับการปิดงานอัตโนมัติเมื่อรวม