Phê duyệt / Được phê duyệt: khái niệm, phê duyệt và code review trong Git

Phê duyệt pull request là gì

Phê duyệt là một đánh giá tích cực về pull request, nghĩa là người review đã kiểm tra mã, không tìm thấy vấn đề nghiêm trọng và cho rằng các thay đổi đã sẵn sàng để merge. Trong giao diện GitHub, đây là nút màu xanh lá cây «Approve» trên trang PR. Sau khi phê duyệt, tác giả (hoặc bất kỳ thành viên nào có quyền ghi) có thể thực hiện merge.

Quy trình phê duyệt là một phần của Branch Protection Rules. Chủ sở hữu kho lưu trữ cấu hình các yêu cầu bắt buộc: số lượng phê duyệt tối thiểu (ví dụ 1 hoặc 2), ai có thể phê duyệt (chủ sở hữu mã, thành viên nhóm) và liệu PR có cần được phê duyệt lại sau khi thay đổi hay không (Dismiss stale reviews). Nếu không có cấu hình quy tắc, phê duyệt là tùy chọn, nhưng trong các nhóm chuyên nghiệp, nó là bắt buộc.

GitLab sử dụng một cơ chế tương tự gọi là Approval Rules. Trong GitLab, bạn có thể cấu hình số lượng phê duyệt cần thiết từ các nhóm khác nhau (ví dụ 2 từ nhà phát triển backend và 1 từ DevOps). Sau khi nhận được tất cả các phê duyệt bắt buộc, PR sẽ tự động được mở khóa để merge với điều kiện đường ống CI/CD màu xanh lá cây.

Các loại review: Approve, Request Changes, Comment

GitHub và GitLab có ba loại review mà người review có thể để lại trên pull request. Mỗi loại có trạng thái và hậu quả khác nhau đối với quy trình merge. Approve màu xanh lá cây, Request Changes màu đỏ, Comment màu xám trung tính. Lựa chọn phụ thuộc vào chất lượng mã và mức sẵn sàng của các thay đổi để được chấp nhận.

Approve — người review xác nhận: mã được viết đúng, đáp ứng tiêu chuẩn, không chứa lỗi rõ ràng và có thể được merge. Approve không có nghĩa là mã hoàn hảo — chỉ là nó đủ tốt cho sản xuất. Nếu có nhận xét nhỏ (phong cách, đặt tên), chúng có thể được để lại dưới dạng nhận xét mà không chặn PR.

Request Changes — người review tìm thấy các vấn đề cần sửa trước khi merge: lỗi logic, lỗ hổng bảo mật, vi phạm kiến trúc, thiếu kiểm thử. Sau Request Changes, PR bị chặn và cần được phê duyệt lại bởi cùng người review để mở khóa (nếu tùy chọn Dismiss stale reviews được bật khi có commit mới).

• Approve — mã sẵn sàng để merge, có thể merge sau khi CI thành công.
• Request Changes — cần sửa bắt buộc, PR bị chặn cho đến khi review lại.
• Comment — nhận xét chung hoặc gợi ý mà không chặn PR.

Cấu hình quy tắc phê duyệt trong kho lưu trữ

Branch Protection Rules là cơ chế của GitHub để kiểm soát chất lượng merge. Được cấu hình trong Settings → Branches cho mỗi nhánh được bảo vệ (main, develop, release/*). Các thông số chính: số lượng phê duyệt bắt buộc, chủ sở hữu mã (CODEOWNERS), kiểm tra CI/CD bắt buộc và cấm push mà không có PR.

Thông số Dismiss stale pull request approvals tự động xóa các phê duyệt nếu một commit mới được thêm vào PR. Điều này đảm bảo rằng người review phê duyệt chính xác phiên bản mã sẽ được merge. Nếu không có cài đặt này, tác giả có thể thêm mã mới sau khi phê duyệt và nó sẽ vào main mà không cần kiểm tra lại.

CODEOWNERS — một tệp trong thư mục gốc của kho lưu trữ, chỉ định người chịu trách nhiệm cho các thư mục khác nhau. Nếu PR ảnh hưởng đến các tệp thuộc về chủ sở hữu mã, sự phê duyệt của họ trở thành bắt buộc. CODEOWNERS cho phép phân phối các lĩnh vực trách nhiệm: nhà phát triển iOS chịu trách nhiệm về các tệp Swift, DevOps về cấu hình Docker, người kiểm thử về các kịch bản kiểm thử.

# Tệp CODEOWNERS mẫu trong thư mục gốc kho lưu trữ

# Nhà phát triển iOS sở hữu mã Swift
*.swift @team/ios-developers

# DevOps sở hữu cấu hình CI/CD
.github/workflows/* @devops-team

# Kỹ sư QA review các kiểm thử
**/tests/* @qa-engineers

# Chủ sở hữu mặc định cho mọi thứ khác
* @tech-leads

Code review trước khi phê duyệt: kiểm tra gì

Code review trước khi phê duyệt là một kiểm tra mã có hệ thống, không phải là một cái nhìn lướt qua diff. Một code review chất lượng bao gồm kiểm tra kiến trúc, logic, phong cách, kiểm thử và bảo mật. Nếu không có kiểm tra này, phê duyệt trở thành một thủ tục chứ không phải là một công cụ kiểm soát chất lượng.

Điều đầu tiên được kiểm tra: logic của các thay đổi — mã có giải quyết được nhiệm vụ không, có tác dụng phụ không, việc xử lý các trường hợp biên có đúng không. Kiểm thử — các kiểm thử mới có bao phủ tất cả các kịch bản không, các kiểm thử hiện có có vượt qua sau khi thay đổi không. Bảo mật — có SQL injection, XSS, rò rỉ dữ liệu nhạy cảm không.

Những gì không nên là đối tượng của review: phong cách định dạng (đã có linters và formatters cho việc này), các quyết định kiến trúc được đưa ra từ trước (chúng được thảo luận trước khi viết mã). Nếu một review vượt quá 400 dòng hoặc mất hơn một giờ, đó là dấu hiệu cho thấy nhiệm vụ quá lớn và cần được phân rã. Thực hành tốt nhất cho review — các phần 200–400 dòng trong vòng 24 giờ sau khi tạo PR.

• Logic — tính đúng đắn của giải pháp, xử lý lỗi, các trường hợp biên.
• Kiểm thử — bao phủ các kịch bản mới, kiểm thử hiện có đạt, không có kiểm thử flaky.
• Bảo mật — không có injection, thoát đầu ra, kiểm soát truy cập dữ liệu.
• Hiệu suất — hiệu quả của thuật toán, truy vấn quá mức, rò rỉ bộ nhớ.
• Tài liệu — tài liệu có được cập nhật không, các chú thích trong phần phức tạp có rõ ràng không.

Quy trình làm việc với phê duyệt trong nhóm

Một quy trình làm việc điển hình với phê duyệt trong một nhóm 5–10 nhà phát triển như sau: một nhà phát triển tạo PR, chỉ định người review (thường là 1–2 người từ nhóm hoặc chủ sở hữu mã), CI/CD chạy các kiểm tra tự động. Sau khi nhận được tất cả các phê duyệt bắt buộc và CI xanh, tác giả thực hiện merge. Thời gian từ khi tạo PR đến merge trung bình từ 2 giờ đến 2 ngày tùy theo độ phức tạp.

GitHub Actions cho phép tự động hóa merge sau khi phê duyệt. Nếu các quy tắc nhánh được cấu hình, GitHub sẽ tự động chặn merge cho đến khi tất cả các điều kiện được đáp ứng. Một số nhóm sử dụng bors-ng hoặc Mergify — các bot tự động merge PR sau khi nhận được tất cả các phê duyệt và CI thành công. Điều này tăng tốc quy trình và loại bỏ yếu tố con người trong merge.

Một cách tiếp cận hiện đại là trunk-based development với các nhánh có vòng đời ngắn. Trong quy trình này, phê duyệt phải được nhận trong vòng vài giờ, nếu không nhiệm vụ sẽ bị coi là lỗi thời và cần đồng bộ lại với main. Các nhóm có văn hóa review cao đặt mục tiêu thời gian phê duyệt không quá 4 giờ làm việc.

Sai lầm khi phê duyệt và cách tránh

Sai lầm phổ biến nhất là phê duyệt hình thức mà không có kiểm tra mã thực sự. Khi PR lớn hoặc hạn chót gần, người review có thể nhấn Approve mà không xem xét các thay đổi. Điều này làm mất giá trị toàn bộ quy trình code review. Giải pháp: đặt giới hạn kích thước PR (không quá 400 dòng) và sử dụng công cụ phân tích mã (SonarQube, CodeClimate) để kiểm tra tự động.

Sai lầm thứ hai là phê duyệt quá khắt khe. Kỳ vọng mã hoàn hảo sẽ chặn sự phát triển. Người review đôi khi yêu cầu sửa các nhận xét về phong cách không ảnh hưởng đến chất lượng. Giải pháp: phân biệt rõ ràng giữa nhận xét bắt buộc (chặn) và gợi ý tùy chọn (nhận xét). GitHub cho phép chỉ định rõ liệu một nhận xét có tính chất chặn hay không.

Sai lầm thứ ba là phê duyệt mà không kiểm tra CI/CD. Ngay cả khi mã có vẻ đúng, nó có thể không biên dịch hoặc thất bại trong kiểm thử. Branch Protection được cấu hình sẽ tự động chặn merge khi CI đỏ, nhưng một số nhóm tắt bảo vệ này để tăng tốc. Giải pháp: luôn kiểm tra trạng thái CI trước khi phê duyệt và không bao giờ phê duyệt PR có đường ống màu đỏ.

• Phê duyệt hình thức — thiếu kiểm tra mã thực sự. Giải pháp: giới hạn 400 dòng mỗi PR.
• Quá khắt khe — chặn vì nhận xét về phong cách. Giải pháp: chia thành blocking và optional.
• Bỏ qua CI — phê duyệt khi đường ống đỏ. Giải pháp: luôn kiểm tra trạng thái kiểm thử.
• Chỉ định tác giả — phê duyệt bởi tác giả PR. Giải pháp: cấu hình Branch Protection chống tác giả.