Login

Quy trình pull request cho nhóm nhỏ: ngắn, nhanh và rõ ràng

  • author-image

    Nguyễn Đình Cường

  • blog-tag
  • blog-comment 0 comment
  • created-date 09 Nov, 2026
blog-thumbnail

Pull request (PR) là cổng kiểm soát giữa mã của một người và mã của cả nhóm. Quy trình PR tốt giúp bắt lỗi sớm, chia sẻ kiến thức và giữ nhánh chính luôn ổn định. Quy trình tệ biến PR thành nút thắt cổ chai mà ai cũng ngại. Bài này đề xuất quy trình gọn nhẹ cho nhóm nhỏ.

Mục tiêu của một quy trình PR

  • Chất lượng: phát hiện lỗi logic, vấn đề bảo mật, thiết kế kém trước khi vào nhánh chính.
  • Chia sẻ kiến thức: ít nhất hai người hiểu mỗi thay đổi.
  • Nhất quán: mã nguồn theo một phong cách chung.
  • Truy vết: lịch sử lý do vì sao thay đổi được thực hiện.

Bước 1: giữ PR nhỏ

Đây là yếu tố quan trọng nhất. PR nhỏ dễ review, ít xung đột và cho phản hồi nhanh. Một hướng dẫn thực tế: PR tập trung vào một mục đích, đủ nhỏ để người khác review trong khoảng vài chục phút. Nếu thay đổi lớn, hãy chia thành nhiều PR liên tiếp hoặc dùng feature flag để gộp từng phần an toàn. Đừng trộn lẫn việc sửa lỗi với việc định dạng lại toàn bộ file.

Bước 2: mô tả PR rõ ràng

Dùng mẫu mô tả để người review không phải đoán. Tạo file mẫu, ví dụ .github/pull_request_template.md:

## Muc dich
Mo ta ngan: thay doi nay giai quyet van de gi?

## Cach lam
Nhung diem chinh trong cach tiep can.

## Cach kiem tra
Cac buoc de nguoi review tu thu.

## Checklist
- [ ] Da them hoac cap nhat kiem thu
- [ ] CI da xanh
- [ ] Da tu review code cua minh

Kèm ảnh chụp màn hình cho thay đổi giao diện và liên kết tới công việc liên quan.

Bước 3: để máy làm việc trước

Trước khi con người xem, CI nên chạy kiểm thử, lint và định dạng mã. Người review không phải bàn chuyện dấu cách hay dấu chấm phẩy. Hãy thiết lập quy tắc bảo vệ nhánh chính (branch protection) để:

  1. Bắt buộc có PR, không đẩy thẳng vào nhánh chính.
  2. Yêu cầu kiểm tra CI phải qua.
  3. Yêu cầu ít nhất một lượt phê duyệt.
  4. Giải quyết hết các bình luận trước khi gộp.

Bước 4: review nhanh và có văn hóa tốt

  • Đặt thời hạn: ví dụ phản hồi lần đầu trong vòng một ngày làm việc. PR nằm chờ lâu làm mất đà và sinh xung đột.
  • Phân biệt mức độ: đánh dấu rõ bình luận nào bắt buộc sửa, bình luận nào chỉ là gợi ý (nhãn như 'nit:').
  • Nói về mã, không về người: 'đoạn này có thể gây lỗi khi danh sách rỗng' thay vì 'bạn viết sai'.
  • Giải thích lý do và đề xuất cách thay thế khi chê.
  • Khen điều tốt: ghi nhận giải pháp hay cũng là một phần của review.
  • Chấp nhận khác biệt phong cách nếu không ảnh hưởng chất lượng.

Bước 5: gộp và dọn dẹp

Chọn một cách gộp thống nhất trong nhóm. Squash merge giữ lịch sử nhánh chính gọn gàng bằng một commit cho mỗi PR; merge commit giữ lại toàn bộ lịch sử chi tiết; rebase cho lịch sử thẳng. Không có đáp án tuyệt đối, hãy chọn và nhất quán. Sau khi gộp, xóa nhánh phụ và theo dõi CI trên nhánh chính.

Gợi ý phân công review

  • Dùng file CODEOWNERS để tự động gán người review cho từng thư mục quan trọng.
  • Luân phiên reviewer để kiến thức không tập trung ở một người.
  • Người mới nên được review kỹ hơn nhưng cũng nên được tham gia review người khác để học.

Lỗi thường gặp

  1. PR khổng lồ khiến reviewer bấm duyệt cho xong.
  2. Không có mô tả, người review phải tự mò.
  3. Tranh luận kéo dài về sở thích cá nhân.
  4. Gộp khi CI đỏ vì 'lỗi này không liên quan'.
  5. PR bị bỏ rơi nhiều ngày.

Kết luận

Quy trình PR tốt dựa trên vài nguyên tắc đơn giản: thay đổi nhỏ, mô tả rõ, máy kiểm tra trước, người xem nhanh và tử tế. Hãy áp dụng mẫu mô tả và quy tắc bảo vệ nhánh trong tuần này để thấy hiệu quả.

Muốn rèn kỹ năng làm việc nhóm với Git và review mã nguồn, bạn có thể tham khảo các khóa học tại codebem.com.

author_photo
Nguyễn Đình Cường

0 comment