Merge Request (MR): nó là gì, cách tạo và quy trình đánh giá

Merge Request (MR) là gì?

Merge Request (MR) — yêu cầu tích hợp các thay đổi từ một nhánh Git sang nhánh khác, bắt đầu quy trình đánh giá mã và kiểm tra tự động. Không giống như hợp nhất trực tiếp qua bảng điều khiển, MR tạo ra một quy trình chính thức: nhà phát triển mô tả các thay đổi, chỉ định người đánh giá, khởi chạy CI/CD và nhận phản hồi trước khi áp dụng thay đổi. Đây là thành phần chính của GitLab, nhưng cơ chế tương đương trong GitHub được gọi là Pull Request (PR).

Theo GitLab Documentation, 2026, hơn 80 triệu Merge Requests được tạo trong GitLab mỗi năm. Mỗi MR chứa bốn thành phần chính: mô tả với bối cảnh thay đổi, danh sách commit, sự khác biệt mã (diff) và thảo luận (chuỗi thảo luận). Nếu thiếu một trong các thành phần này, MR được coi là không đầy đủ.

Merge Request (MR) giải quyết ba nhiệm vụ: ngăn chặn các thay đổi trực tiếp vào nhánh được bảo vệ (main, develop), cung cấp kiểm soát chất lượng thông qua đánh giá và lưu giữ lịch sử thảo luận cho các nhà phát triển trong tương lai. Trong GitLab, trạng thái MR được hiển thị trong giao diện với các chỉ thị màu sắc: xám cho Draft, cam cho đang chờ, xanh lá cho Approved, tím cho Merged và đỏ cho Closed.

Thuật ngữ: MR, PR và CR

Trên các nền tảng Git khác nhau, Merge Request được gọi bằng những tên khác nhau. GitLab sử dụng “Merge Request” (MR), GitHub sử dụng “Pull Request” (PR). Tương tự là Change Request (CR) trong Gerrit. Cả ba đều chỉ cùng một quy trình: yêu cầu tích hợp các thay đổi thông qua đánh giá mã. Việc chọn thuật ngữ chỉ phụ thuộc vào nền tảng được sử dụng trong dự án.

# Tạo nhánh với các thay đổi
git checkout -b feature/add-auth
git commit -m "Add OAuth2 authentication flow"
git push origin feature/add-auth

# Bạn có thể tạo MR qua giao diện GitLab/GitHub hoặc CLI:
gh pr create --title "Add OAuth2 authentication flow" \
  --body "Implements OAuth2 with Google and Apple providers" \
  --reviewer "team-lead"

MR so với PR: sự khác biệt giữa GitLab và GitHub

Merge Request trong GitLab và Pull Request trong GitHub là các cơ chế chức năng giống hệt nhau với tên gọi khác nhau. Sự khác biệt là do lịch sử: GitLab ban đầu định vị mình là giải pháp thay thế Self-Hosted cho GitHub và chọn thuật ngữ “merge request” cho quy trình hợp nhất. GitHub, ra mắt sớm hơn, sử dụng “pull request” — yêu cầu “kéo” (pull) các thay đổi vào nhánh chính.

Theo GitHub Docs, 2024, cả hai công cụ đều hỗ trợ cùng một tập tính năng: mô tả Markdown, chỉ định người đánh giá, nhận xét trên các dòng mã cụ thể, trạng thái kiểm tra và hợp nhất tự động khi đáp ứng điều kiện. Sự khác biệt liên quan đến giao diện và khả năng bổ sung.

Cách tạo Merge Request: hướng dẫn từng bước

Việc tạo Merge Request (MR) bắt đầu bằng việc xuất bản một nhánh có thay đổi lên kho lưu trữ từ xa. Sau khi push lên GitLab hoặc GitHub, giao diện hiển thị nút “Create Merge Request” hoặc “Compare & Pull Request”. Nhà phát triển điền mô tả, chỉ định nhánh đích (thường là develop hoặc main), chỉ định người đánh giá và đính kèm nhãn.

Theo GitLab Documentation, 2025, một MR tiêu chuẩn chứa tiêu đề tối đa 72 ký tự, mô tả với mẫu và liên kết đến issue. Mô tả nên trả lời các câu hỏi: đã làm gì, tại sao, đã kiểm thử như thế nào. GitLab hỗ trợ tự động đóng issue khi hợp nhất thông qua các từ khóa Closes, Fixes, Resolves.

# Ví dụ về mẫu .gitlab/merge_request_templates/default.md
## What does this MR do?

[Mô tả ngắn về thay đổi: cái gì và tại sao]

## How to test

1. Chạy ./gradlew test
2. Kiểm tra LoginActivity với token thử nghiệm
3. Đảm bảo không có hồi quy trong AuthManager

## Related issues

Closes #142

Vòng đời MR: từ Draft đến Merged

Merge Request (MR) trải qua năm trạng thái trong GitLab. Đầu tiên là Draft (bản nháp), được đánh dấu bằng tiền tố “Draft:” trong tiêu đề, chặn hợp nhất. Khi sẵn sàng, nhà phát triển bỏ Draft và MR chuyển sang trạng thái Opened — quá trình đánh giá mã bắt đầu và đường ống CI/CD khởi động.

Theo GitLab Docs, 2024, ở trạng thái Opened, người đánh giá xem xét diff, để lại nhận xét và yêu cầu thay đổi thông qua Resolve Threads. Khi tất cả các luồng được giải quyết và CI/CD thành công, nhà phát triển chịu trách nhiệm đặt Approve. Sau đó, MR có thể được hợp nhất bằng nút Merge hoặc chờ hợp nhất tự động (Auto-merge).

GitLab hỗ trợ ba tùy chọn trạng thái cuối: Merged (đã hợp nhất thành công), Closed (đã đóng mà không hợp nhất, ví dụ khi từ bỏ tính năng) và Reopened (mở lại sau khi đóng). Mỗi trạng thái được ghi lại trong Dòng thời gian hoạt động của MR để kiểm toán.

Trạng thái tự động và trình kích hoạt

GitLab tự động cập nhật trạng thái Merge Request khi có sự kiện: push commit mới đặt lại Approvals, khi đường ống CI thành công trạng thái thành Pipeline passed, khi thất bại — Pipeline failed (hợp nhất bị chặn). Có thể cấu hình Auto-merge: MR tự động được hợp nhất sau khi CI thành công và nhận được tất cả các phê duyệt cần thiết.

• Draft — bản nháp, CI chạy nhưng hợp nhất bị chặn
• Opened — sẵn sàng đánh giá, đã chỉ định người đánh giá, đường ống hoạt động
• Approved — đã nhận đủ số lượng phê duyệt cần thiết
• Merged — các thay đổi đã được hợp nhất vào nhánh đích
• Closed — đã đóng mà không hợp nhất

Quy tắc đánh giá mã trong Merge Request

Đánh giá mã trong Merge Request (MR) là giai đoạn bắt buộc trong hầu hết các dự án thương mại. Theo nghiên cứu của SmartBear, 2023, đánh giá mã với MR giảm số lượng lỗi từ 30–60% và tăng tốc độ hội nhập cho nhà phát triển mới. Quy tắc chính là mỗi MR được kiểm tra bởi ít nhất một, tốt nhất là hai nhà phát triển không tham gia viết mã.

Kiểm tra MR bao gồm năm tiêu chí: tính đúng đắn logic, tuân thủ kiểu mã, độ phủ kiểm thử, bảo mật và hiệu suất. Trong GitLab, có thể cấu hình Required Approvals — số lượng phê duyệt bắt buộc trước khi hợp nhất, ví dụ 2 phê duyệt cho main và 1 cho develop.

Thảo luận trong MR được tiến hành trong các Chuỗi (Threads) — nhận xét trên các dòng mã cụ thể. Mỗi chuỗi phải được giải quyết trước khi hợp nhất. Để tăng tốc đánh giá, nên giới hạn kích thước MR: 200–400 dòng thay đổi. Theo Google Research (2022), MR lớn hơn 400 dòng được đánh giá kém hiệu quả hơn 30%.

Đường ống CI/CD trong Merge Request

Khi tạo Merge Request (MR), đường ống CI/CD tự động khởi động. Trong GitLab, điều này xảy ra thông qua tệp .gitlab-ci.yml, trong GitHub thông qua quy trình GitHub Actions. Đường ống bao gồm xây dựng dự án, kiểm thử đơn vị, trình lint, phân tích tĩnh (SAST) và kiểm tra độ phủ mã.

Theo GitLab Blog, 2024, trạng thái đường ống được hiển thị trực tiếp trong MR: dấu kiểm xanh (passed), chữ thập đỏ (failed) hoặc vòng tròn vàng (running). Nếu đường ống thất bại, GitLab chặn nút Merge cho đến khi sửa xong. Trong cài đặt, có thể bật “Merge when pipeline succeeds” — hợp nhất tự động sau khi đường ống thành công.

# .gitlab-ci.yml — ví dụ cho dự án Android
test:
  stage: test
  script:
    - ./gradlew ktlintCheck
    - ./gradlew testDebugUnitTest
  only:
    - merge_requests

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

Phương pháp hợp nhất: Squash, Merge Commit, Fast-Forward

GitLab và GitHub cung cấp ba phương pháp hợp nhất cho Merge Request. Lựa chọn phụ thuộc vào chính sách nhóm và độ sạch mong muốn của lịch sử. Merge Commit tạo một commit hợp nhất riêng biệt, bảo toàn toàn bộ lịch sử nhánh tính năng. Squash kết hợp tất cả commit của nhánh thành một commit duy nhất trên nhánh đích. Fast-Forward áp dụng các commit một cách tuyến tính mà không có commit hợp nhất.

Theo GitLab Docs, 2025, Squash được ưu tiên cho các dự án có mật độ commit cao (20+ commit trong một nhánh tính năng). Fast-Forward là bắt buộc cho Phát triển Trunk-Based. Merge Commit được sử dụng trong Git Flow để bảo toàn ngữ nghĩa phân nhánh.

• Merge Commit — bảo toàn lịch sử, tạo commit hợp nhất, phù hợp cho Git Flow
• Squash — kết hợp tất cả commit thành một, lịch sử sạch, mất các commit trung gian
• Fast-Forward — lịch sử tuyến tính không có commit hợp nhất, bắt buộc trong TBD

Thực hành tốt nhất: cách viết MR tốt

Một Merge Request (MR) chất lượng giảm thời gian đánh giá và số lượng lỗi. Quy tắc đầu tiên là một MR giải quyết một nhiệm vụ. Nếu các thay đổi ảnh hưởng đến nhiều tính năng không liên quan, chúng nên được chia thành các MR riêng biệt. Thứ hai, tiêu đề MR nên mang tính thông tin: “Add OAuth2 authentication with Google provider” thay vì “Fix stuff” hoặc “Update code”.

Theo Google Engineering Practices, 2024, một MR tốt chứa mô tả bối cảnh: tại sao các thay đổi là cần thiết, chúng đã được kiểm thử như thế nào và những rủi ro nào tồn tại. Kích thước MR không được vượt quá 400 dòng thay đổi. Nếu khối lượng lớn hơn, nhiệm vụ cần được phân rã thành các nhiệm vụ con. Đối với tài liệu và kiểm thử, các trường hợp ngoại lệ được chấp nhận nhưng phải có giải thích.

Merge Request (MR) nên bao gồm các kiểm thử tự động cho chức năng mới. Trong GitLab, có thể cấu hình chính sách Coverage Check — MR tự động bị chặn nếu độ phủ mã giảm xuống dưới ngưỡng (ví dụ 80%). Điều này đảm bảo rằng chức năng mới không làm giảm chất lượng tổng thể của dự án.

• Một MR — một nhiệm vụ: phân rã các thay đổi lớn thành nhiều MR nhỏ
• Mô tả với mẫu: sử dụng .gitlab/merge_request_templates để đồng nhất
• Kích thước tối đa 400 dòng: MR lớn được đánh giá chậm hơn và nhiều lỗi hơn
• Kiểm thử bắt buộc: các tính năng mới phải được bao phủ bởi kiểm thử đơn vị

Mẫu mô tả MR

GitLab hỗ trợ các mẫu Merge Request thông qua tệp .gitlab/merge_request_templates/. Mẫu bao gồm các phần: đã làm gì, cách kiểm thử, nhiệm vụ liên quan và danh sách kiểm tra. Sử dụng mẫu giúp tăng tốc tạo MR và đảm bảo các nhà phát triển không quên bao gồm thông tin quan trọng. Trong mô tả MR, các issue liên quan (Closes #N) phải được chỉ định để tự động đóng nhiệm vụ khi hợp nhất.