Pull Request trong Git: Hướng dẫn hoạt động như thế nào

Pull request đã giúp các nhóm của tôi tránh lỗi, thống nhất các quyết định triển khai và học hỏi từ mã của nhau. Trong hướng dẫn này, tôi sẽ chỉ bạn cách sử dụng pull request trên các nền tảng dựa trên Git để review code một cách an toàn.

Nếu bạn mới bắt đầu với Git, tôi khuyến nghị bạn học các khóa Introduction to Git và Introduction to GitHub Concepts để tìm hiểu về kiểm soát phiên bản và sự khác nhau giữa Git và GitHub. Ngoài ra, tôi thấy Git Cheat Sheet mà bạn có thể tải về là một tài liệu tham khảo hữu ích vì nó có tất cả thuật ngữ và lệnh Git thường dùng nhất.

Pull Request là gì?

Pull request thực chất là một cách đề xuất thay đổi đối với mã. Hãy hình dung bạn đang làm việc trên một tính năng hoặc một nhánh riêng, pull request cho phép bạn đề nghị hợp nhất các thay đổi đó vào mã nguồn chính. Việc này thường diễn ra sau khi người khác đã có cơ hội review. Pull request là phần cốt lõi của phát triển cộng tác, đặc biệt khi làm việc theo nhóm.

Đáng lưu ý là trên GitLab, quy trình tương tự được gọi là “Merge Request.” 

Pull Request hoạt động như thế nào?

Các bước sau đây phác thảo workflow cơ bản của một pull request:

1. Thực hiện thay đổi với script (mã) trong một nhánh tính năng.
2. Commit các thay đổi này trong kho lưu trữ cục bộ của bạn.
3. Push nhánh lên kho lưu trữ từ xa như GitHub.
4. Mở một pull request để đề xuất các thay đổi vào nhánh chính.
5. Yêu cầu review cho các thay đổi được đề xuất.
6. Merge hoặc đóng pull request tùy theo kết quả.

Workflow này cho mọi lập trình viên cơ hội review mã và phát hiện vấn đề tiềm ẩn trước khi đẩy mã lên môi trường sản xuất.

Các vai trò chính trong quy trình pull request bao gồm:

• Người đóng góp (Contributor): Lập trình viên thực hiện thay đổi và mở pull request.
• Người review (Reviewer): Lập trình viên review các thay đổi mã được đề xuất để gợi ý cải tiến và đảm bảo chất lượng mã.
• Người duy trì (Maintainer): Quản lý dự án, người sở hữu dự án và có quyền phê duyệt hoặc từ chối pull request. 

Tôi khuyến nghị học khóa Intermediate Git để biết cách tạo nhánh trong Git và cách cộng tác từ xa với thành viên nhóm.

Tạo một Pull Request (kèm ví dụ)

Giả sử bạn phát hiện lỗi trong dòng giới thiệu của tệp README của dự án. Bạn muốn sửa lỗi này mà không ảnh hưởng đến nhánh chính. Hãy làm theo các bước dưới đây:

Bước 1: Tạo nhánh mới

Đi tới thư mục dự án và mở terminal để chạy lệnh dưới đây. Dòng này tạo một nhánh khác.

git checkout -b fix-readme-typoĐược hỗ trợ bởi

Bước 2: Thực hiện thay đổi

Để sửa tệp, mở README.md trong trình soạn thảo mã, sửa lỗi chính tả, rồi lưu tệp.

Bước 3: Commit các thay đổi

Stage và commit các thay đổi bằng lệnh dưới đây:

git add README.md
git commit -m "Fix typo in README"Được hỗ trợ bởi

Bước 4: Push nhánh lên GitHub

Tải nhánh lên kho lưu trữ.

git push origin fix-readme-typoĐược hỗ trợ bởi

Bước 5: Mở GitHub và tạo pull request

Giờ hãy mở tài khoản GitHub của bạn và thực hiện:

• Đi tới kho lưu trữ của bạn trên GitHub.

• Chọn nhắc Compare & pull request cho nhánh bạn vừa push.

• Thêm tiêu đề như Fix typo in README và tùy chọn viết mô tả ngắn.

• Chọn nhánh cơ sở của bạn (thường là main) và so sánh với nhánh tính năng của bạn.

Bước 6: Yêu cầu review và gửi

Nếu dự án của bạn có các lập trình viên khác, bạn có thể yêu cầu người review hoặc thêm nhãn nếu dự án sử dụng. Sau đó bấm Create pull request.

Xem dự án của chúng tôi trên Performing a Code Review để hiểu cách review và thực hiện thay đổi trước khi đẩy mã lên sản xuất.

Thực hành tốt nhất cho Pull Request

Dưới đây là các thực hành tốt nhất để đảm bảo chất lượng phát triển khi tạo pull request:

• Giữ pull request gọn và đơn giản: Luôn bắt đầu với một pull request cho mỗi tính năng bạn muốn đề xuất. Điều này giúp người review theo dõi và kiểm thử thay đổi của bạn, đồng thời giảm thiểu khả năng phát sinh lỗi.
• Viết thông điệp commit và mô tả rõ ràng: Cung cấp thông điệp commit giàu ngữ cảnh để giải thích các chỉnh sửa. Bối cảnh này giúp người review hiểu ý định của bạn mà không phải lần mò trong mã.  
• Tận dụng draft pull request để nhận phản hồi sớm: Nếu công việc chưa hoàn thành nhưng bạn muốn nhận góp ý, hãy tạo draft pull request. Nó cho biết mã của bạn đang trong quá trình thực hiện và kêu gọi thảo luận mà chưa cần merge ngay.
• Kiểm thử kỹ và chia sẻ bối cảnh: Luôn kiểm tra kỹ các thay đổi để đảm bảo mọi thứ hoạt động đúng như mong đợi.

Pull Request trong các workflow Git

Dưới đây là tổng quan nhanh về cách các thiết lập nhóm khác nhau sử dụng pull request.

• Feature branching: Phổ biến trong các nhóm nhỏ và kho riêng tư. Workflow này tạo một nhánh mới cho mỗi tính năng. 

• Forking workflow: Được dùng trong các dự án mã nguồn mở. Quy trình forking yêu cầu người đóng góp fork (sao chép) kho chính vào tài khoản của họ. Họ thực hiện thay đổi trong bản fork rồi mở pull request tới bản gốc.

• GitFlow: Một workflow có cấu trúc sử dụng các nhánh dài hạn như main, develop, release và hotfix. Thường được dùng bởi các nhóm lớn với chu kỳ phát hành phức tạp hơn.

Quy tắc ứng xử khi tạo Pull Request

Có thể mắc lỗi ứng xử, vì vậy pull request cũng có những phép tắc riêng:

• Tôn trọng và cụ thể: Tập trung vào mã, không nhằm vào cá nhân.
• Giữ pull request tập trung: Tránh trộn các thay đổi không liên quan trong một pull request. Bỏ qua điều này chỉ làm phức tạp việc review và phản hồi.
• Phản hồi có cân nhắc với góp ý: Ghi nhận mã viết tốt và các đề xuất cải thiện.
• Đừng để pull request treo quá lâu: Luôn cố gắng review và xử lý pull request nhanh nhất có thể để tránh trì hoãn cập nhật.
• Đặt câu hỏi: Nếu điều gì đó chưa rõ, hãy xin làm rõ thay vì suy đoán ý định để tránh hiểu lầm.
• Đề xuất cải tiến: Khi phù hợp, hãy đưa ra lời khuyên có thể hành động hoặc cách tiếp cận thay thế thay vì chỉ nêu vấn đề.

Workflow và thực hành nâng cao cho Pull Request

Nếu bạn là lập trình viên giàu kinh nghiệm muốn cộng tác trơn tru hơn, nâng cao chất lượng mã và mở rộng quy trình pull request, dưới đây là vài mẹo thực tế để mài sắc workflow của bạn.

Workflow thông minh hơn

Nhiều workflow Git xử lý pull request theo cách khác nhau. Như đã đề cập, Feature branching phù hợp cho nhóm nhỏ vì tính đơn giản. Tuy nhiên, khi đội ngũ lớn dần, việc duy trì có thể trở nên thách thức.

Forking được khuyến nghị cho dự án mã nguồn mở nhưng có thể làm phát sinh chi phí đồng bộ và review đóng góp từ bên ngoài. Tương tự, GitFlow phù hợp trong phát triển tốc độ cao, dù độ phức tạp có thể làm chậm quy trình. 

Tự động hóa và tích hợp

Pull request hiện đại có CI/CD Checks, tự động hóa “rào chắn chất lượng” bằng cách tích hợp công cụ CI chạy kiểm thử và linter, cũng như triển khai bản xem trước cho mỗi PR. Điều này đảm bảo chỉ mã đạt chuẩn định nghĩa mới được merge.

Các nền tảng như GitHub Actions và GitLab Pipelines cũng cho phép tự động hóa. Các quy trình này bao gồm chạy unit test, build và triển khai môi trường xem trước, giảm công sức thủ công và phát hiện vấn đề sớm.

Tối ưu việc review

Luôn giữ pull request nhỏ gọn và tập trung để có thể được review nhanh chóng và kỹ lưỡng. Sử dụng mẫu với các trường rõ ràng như “Có gì thay đổi” và “Cách kiểm thử” giúp người đóng góp cung cấp thông tin súc tích, phù hợp, làm cho việc review hiệu quả hơn.

Bạn cũng nên lưu ý rằng đặt câu hỏi thay vì yêu cầu mệnh lệnh sẽ thúc đẩy đối thoại xây dựng và học hỏi. Nếu bạn xác định thời gian phản hồi cho review, quy trình sẽ có thể dự đoán và tránh trì hoãn.

Chỉ số và công cụ hiện đại

Tôi cũng khuyên bạn theo dõi kích thước PR, thời gian review và tỷ lệ merge để xác định nút thắt và cải thiện hiệu suất workflow. Để việc review và merge dễ hơn, hãy thử dùng stacked pull request. Cách này chia nhỏ tính năng lớn thành các PR nhỏ, có liên kết, xây dựng chồng lên nhau. 

Ngoài ra, bạn có thể tích hợp các công cụ AI như GitHub Copilot hoặc CodeWhisperer khi dùng pull request. Những công cụ này sẽ giúp bạn phát hiện sớm vấn đề tiềm ẩn và gợi ý cách khắc phục.

Pull Request và Merge Request

Trên GitHub và GitLab, Pull Request (PR) và Merge Request (MR) được dùng thay thế cho nhau. Mặc dù có cùng mục đích, mỗi nền tảng xử lý chúng theo cách khác nhau.

Bảng dưới đây so sánh PR và MR để làm nổi bật các khác biệt này.

Kết luận

Pull request là kiến thức bắt buộc cho bất kỳ dự án nghiêm túc nào. Như bạn đã thấy (và tôi hy vọng bạn đánh giá cao), chúng cho phép các nhóm review, thảo luận và cải thiện mã một cách cộng tác.

Tiếp tục nâng cao kỹ năng của bạn với vai trò lập trình viên. Xem các lộ trình kỹ năng Git Fundamentals và GitHub Foundations của chúng tôi để trở thành chuyên gia về Git.