Pull Request: nó là gì, quy trình tạo và đánh giá mã

Pull Request là gì?

Pull Request (PR) là một yêu cầu chính thức để đưa các thay đổi từ nhánh này sang nhánh khác trong hệ thống kiểm soát phiên bản phân tán. PR là một yếu tố trung tâm của phát triển cộng tác trên các nền tảng GitHub, GitLab và Bitbucket, kết hợp thảo luận mã, kiểm thử tự động và quy trình phê duyệt thay đổi.

Tên gọi “Pull Request” phản ánh bản chất của thao tác: nhà phát triển yêu cầu (request) chủ sở hữu kho lưu trữ “kéo” (pull) các thay đổi của họ. Thuật ngữ này được GitHub giới thiệu vào năm 2008 — trước đó, một cơ chế tương tự tồn tại dưới dạng các bản vá và merge requests (thuật ngữ của GitLab). Ngày nay, PR là tiêu chuẩn thực tế cho phát triển nhóm với Git.

Theo GitHub Octoverse, 2025, 89% dự án mã nguồn mở yêu cầu tạo PR để thực hiện thay đổi. Trong phát triển doanh nghiệp, con số này đạt 95%. PR không chỉ trở thành một công cụ kỹ thuật mà còn là một phần của văn hóa phát triển: thông qua PR, việc chuyển giao kiến thức, phát hiện lỗi và điều chỉnh các quyết định kiến trúc diễn ra.

Các thành phần của Pull Request

Một PR điển hình bao gồm tiêu đề, mô tả, danh sách các tệp đã thay đổi (diff), nhận xét của người đánh giá và trạng thái kiểm tra CI. Mỗi PR được liên kết với một nhánh nguồn và nhánh đích cụ thể, và sau khi hợp nhất có thể tự động bị xóa.

Cách tạo Pull Request

Tạo PR bắt đầu bằng việc xuất bản nhánh tính năng lên kho lưu trữ từ xa. Sau khi push, nhà phát triển mở PR qua giao diện nền tảng hoặc qua CLI (gh, glab). Hãy xem quy trình với GitHub làm ví dụ.

Push nhánh và mở PR

Bước đầu tiên là push nhánh tính năng lên kho lưu trữ từ xa và tạo Pull Request qua giao diện web hoặc dòng lệnh.

# Tạo và push nhánh tính năng
git checkout -b feature/biometric-auth
git add src/auth/
git commit -m "feat: add biometric authentication"
git push -u origin feature/biometric-auth

# Tạo PR qua GitHub CLI
gh pr create --title "feat: add biometric authentication" \
  --body "Implements fingerprint and face recognition login.
  Closes #142" \
  --base develop

Sau khi tạo PR, GitHub tự động chạy các pipeline CI (GitHub Actions), kiểm tra xung đột với nhánh đích và mời người đánh giá. Mẫu mô tả PR có thể được cấu hình qua .github/PULL_REQUEST_TEMPLATE.md để tất cả PR đều chứa các phần bắt buộc: mục tiêu, thay đổi, kiểm thử, nhiệm vụ liên quan.

Mô tả và gắn thẻ

Mô tả PR chất lượng bao gồm: liên kết đến nhiệm vụ (issue/ticket), mô tả ngắn gọn về các thay đổi, hướng dẫn kiểm thử và danh sách các thay đổi liên quan. Nhãn (bug, feature, refactoring) giúp phân loại PR, trong khi assignees và reviewers được chỉ định tự động qua CODEOWNERS.

# Chỉ định người đánh giá qua CODEOWNERS (tệp trong thư mục gốc kho lưu trữ)
# Ví dụ .github/CODEOWNERS:
# src/auth/ @team-auth @senior-dev
# src/api/ @team-backend
# *.kt @kotlin-team

# Tạo PR với việc chỉ định người đánh giá qua gh cli
gh pr create --reviewer "team-auth" --label "feature"

CODEOWNERS là một cơ chế tiêu chuẩn của GitHub/GitLab để tự động chỉ định người đánh giá dựa trên các tệp đã thay đổi. Ví dụ, bất kỳ thay đổi nào trong thư mục src/auth/ đều tự động chỉ định team-auth và senior-dev làm người đánh giá. Điều này tăng tốc quy trình và đảm bảo những người phù hợp xem được PR.

Cập nhật PR dựa trên đánh giá

Sau khi nhận được nhận xét của người đánh giá, nhà phát triển thực hiện sửa chữa trong cùng nhánh tính năng và push các commit mới — PR tự động cập nhật. Điều quan trọng là không viết lại lịch sử (rebase) trong nhánh tính năng đã xuất bản nếu PR đã mở, vì điều này phá vỡ các liên kết đến các commit cụ thể trong nhận xét.

# Thực hiện thay đổi dựa trên nhận xét của người đánh giá
git checkout feature/biometric-auth
# sửa mã
git commit -m "fix: handle biometric timeout per review"
git push

# PR sẽ tự động cập nhật
# Sau khi phê duyệt — hợp nhất PR qua giao diện GitHub

Quy trình đánh giá mã

Đánh giá mã là một yếu tố trung tâm của Pull Request. Người đánh giá kiểm tra các thay đổi về tính chính xác, phong cách mã, bảo mật và nhất quán kiến trúc. Một đánh giá chất lượng không chỉ ngăn ngừa lỗi mà còn truyền bá kiến thức về cơ sở mã trong nhóm.

Engineering Practices của Google (2025) khuyến nghị các nguyên tắc đánh giá mã sau: người đánh giá phải hiểu bối cảnh của các thay đổi, đưa ra các đề xuất cụ thể thay vì nhận xét chung và tách biệt nhận xét kỹ thuật và phong cách. Thời gian đánh giá không được vượt quá 24 giờ kể từ thời điểm tạo PR.

Đối với phát triển di động, đánh giá mã bao gồm các kiểm tra cụ thể: tương thích với targetSdk, xử lý lifecycle chính xác (Android) / view lifecycle (iOS), không có rò rỉ bộ nhớ (LeakCanary, Instruments), hỗ trợ chủ đề tối và bản địa hóa. Các kiểm tra này có thể được tự động hóa thông qua linters và Detekt/ktlint.

Các loại nhận xét

Các nền tảng PR hỗ trợ ba loại nhận xét: chung (trên toàn bộ PR), nội dòng (trên một dòng mã cụ thể) và đề xuất (với mã thay thế). Đề xuất cho phép áp dụng thay đổi chỉ với một cú nhấp chuột, tăng tốc quy trình và giảm số lần lặp.

Sau khi tất cả nhận xét được giải quyết và các kiểm tra CI đã qua, người đánh giá gửi phê duyệt (Approved). PR có thể được hợp nhất. GitHub và GitLab hỗ trợ các quy tắc bảo vệ nhánh: số lượng phê duyệt bắt buộc, kiểm tra CI bắt buộc và cấm push vào main mà không có PR. Đối với các dự án di động, bảo vệ nhánh cũng bao gồm xác minh bản dựng: PR không thể được hợp nhất nếu ứng dụng không xây dựng được (gradle build failed / xcodebuild failed).

Giải quyết xung đột trong PR

Xung đột hợp nhất trong Pull Request là tình huống phổ biến khi làm việc nhóm tích cực. Các nền tảng cung cấp giải quyết xung đột qua giao diện web (cho xung đột đơn giản) hoặc khuyến nghị giải quyết cục bộ. GitHub Actions tự động kiểm tra khả năng hợp nhất với mỗi lần push vào nhánh tính năng và đánh dấu PR là xung đột nếu không thể hợp nhất.

Thực hành tốt nhất về Pull Request

Các Pull Requests hiệu quả tăng tốc đánh giá mã và giảm số lượng lỗi. Một nghiên cứu của SmartBear (2025) cho thấy PR có kích thước lên đến 200 dòng mã nhận được nhiều nhận xét có ý nghĩa gấp 2 lần so với PR có hơn 1000 dòng và thời gian đánh giá giảm 3 lần.

• PR nhỏ — kích thước tối ưu là 100-300 dòng. Chia PR lớn thành các phần logic: mỗi PR giải quyết một nhiệm vụ. Điều này đơn giản hóa việc đánh giá và giảm khả năng xảy ra xung đột
• Mô tả rõ ràng — tiêu đề theo Conventional Commits (feat:, fix:, refactor:), phần thân chứa “cái gì và tại sao” thay vì “như thế nào” (mã tự nó đã nói lên). Mẫu: mục tiêu → thay đổi → kiểm thử → các issues liên quan
• Phản hồi nhanh — đánh giá trong vòng 24 giờ. Nếu PR chờ hơn một ngày, nhóm sẽ mất bối cảnh và số lượng xung đột hợp nhất tăng lên
• Tự động hóa — linters, trình định dạng và kiểm thử phải chạy tự động khi tạo PR. Không cho phép hợp nhất PR với các kiểm tra CI đỏ
• Draft PR — sử dụng để thảo luận kiến trúc sớm. Draft PR không yêu cầu đánh giá và không thể được hợp nhất, nhưng cho phép hiển thị mã cho đồng nghiệp ở giai đoạn đầu

Các thực hành bổ sung: không tạo PR vào tối thứ Sáu (sẽ không có ai đánh giá cho đến thứ Hai), yêu cầu đánh giá từ 1-2 người (nhiều hơn làm chậm quy trình mà không cải thiện chất lượng), sử dụng squash merge để nén lịch sử trước khi hợp nhất. Đối với các dự án di động, cũng nên thêm liên kết đến bản dựng thử nghiệm (Firebase App Distribution / TestFlight) trong mô tả PR để người đánh giá có thể xác minh các thay đổi trong ứng dụng đang chạy.

Pull Request trên các nền tảng khác nhau

Các nền tảng chính để làm việc với Pull Requests là GitHub, GitLab và Bitbucket. Mặc dù có cùng khái niệm, mỗi nền tảng đều có các tính năng đáng xem xét khi chọn công cụ cho nhóm.

GitHub là nền tảng phổ biến nhất với cộng đồng lớn nhất, Actions cho CI/CD và hệ sinh thái ứng dụng rộng lớn (GitHub Marketplace). GitLab nổi bật với CI/CD tích hợp và khả năng triển khai tự lưu trữ hoàn toàn. Bitbucket được tích hợp chặt chẽ với Jira và hệ sinh thái Atlassian, phổ biến trong môi trường doanh nghiệp.

Đối với phát triển di động, việc lựa chọn nền tảng thường được quyết định bởi khả năng CI/CD: GitHub Actions hỗ trợ trình chạy macOS cho bản dựng iOS, GitLab có trình chạy tích hợp cho iOS/Android, Bitbucket tích hợp tốt với Firebase Test Lab. Bất kể nền tảng nào, quy trình PR vẫn giống nhau: nhánh → đánh giá → CI → hợp nhất.