Pull request từ lúc tạo đến khi merge

Bài viết này giúp bạn hiểu Pull Request (PR) là gì, vì sao đây là công cụ để thảo luận về thay đổi, đồng thời hướng dẫn tạo và xem PR ngay trong IDE. Chúng ta cũng sẽ tìm hiểu ba quy tắc để có một commit tốt. Đây là kiến thức nền tảng quan trọng: Claude Code có thể chuẩn bị và bình luận về pull request thay bạn, nên hiểu PR là gì và dùng để làm gì sẽ giúp bạn sử dụng tính năng này có chủ đích.

Ví dụ và ảnh chụp giao diện dùng IDE JetBrains; tên và vị trí thao tác có thể khác tùy phiên bản. Hãy dùng repository thực hành riêng. Với dự án thực tế, hãy tuân theo quy tắc về branch, commit và gửi thay đổi của dự án đó.

Vì sao cần Pull Request

Trong nhóm, việc thảo luận thay đổi trước khi đưa chúng vào branch chung rất hữu ích. Pull request tập hợp diff được đề xuất, nhận xét và kết quả kiểm tra tại một nơi. Ngay cả trong dự án cá nhân, bạn cũng có thể dùng PR để tự xem lại công việc trước khi merge.

Trong quy trình dùng PR, trước tiên bạn tạo một đề xuất merge. GitHub gọi nó là Pull Request; một số nền tảng khác gọi là Merge Request. Nhóm sẽ quyết định quy trình cụ thể.

Pull Request là một lời đề nghị chính thức: "hãy lấy (pull) thay đổi của tôi từ branch này và đưa (merge) chúng vào branch chính". Nhưng PR không chỉ là lời đề nghị; đó còn là nơi thảo luận, kiểm tra và cải thiện mã trước khi đưa vào main.

Quy trình làm việc thông thường với Pull Request

Hãy cùng xem từng bước của quy trình phổ biến khi phát triển tính năng mới.

Trước khi tạo branch, hãy kiểm tra branch xuất phát và danh sách commit của nó so với branch đích trên GitHub. PR mới không được chứa các commit cục bộ không liên quan. Đừng tự động gửi chúng chỉ để "đồng bộ": hãy chọn đúng base cho công việc và giữ phần việc trước đó riêng biệt.

Bước 1. Tạo branch cho công việc mới. Trong quy trình PR được minh họa ở đây, bạn bắt đầu trên một branch riêng. Giả sử ta muốn thêm tệp hướng dẫn dành cho người đóng góp, hãy tạo branch feature/add-contribution-guide.

Bước 2. Thực hiện thay đổi và push branch lên GitHub. Trên branch mới, tạo tệp CONTRIBUTING.md (sau khi tạo, nhấn Add) và viết lời nhắn cho các nhà phát triển khác. Sau đó chọn Commit and Push với thông điệp rõ ràng, chẳng hạn docs: Add contribution guide.

Đây là bước then chốt. Pull Request được tạo từ một branch đã tồn tại trên server từ xa. Vì vậy, trước khi tạo PR, bạn phải push branch mới lên GitHub.

Tạo Pull Request từ IDE

Hãy kiểm tra cả hai phía của phần so sánh: base là branch sẽ nhận thay đổi, còn compare/head là branch chứa phần việc của bạn. Xem danh sách commit và diff trước khi tạo PR.

Giờ branch đã có trên GitHub, bạn có thể tạo Pull Request.

Bước 1. Mở tab Pull Requests. Tìm tab Pull Requests trên thanh bên trái của IDE. Mở tab rồi nhấn biểu tượng + (hoặc nút Create Pull Request).

Bước 2. Điền thông tin PR. IDE sẽ mở một biểu mẫu thuận tiện. Bạn cần điền thông tin chính xác. Các trường quan trọng gồm:

1. tiêu đề - IDE thường tự điền tên branch hoặc thông điệp commit cuối cùng; hãy đảm bảo tiêu đề ngắn gọn, dễ hiểu và nêu đúng nội dung thay đổi;
2. mô tả - giải thích chi tiết cho đồng nghiệp bạn đã làm gì và vì sao;
3. người review (Reviewers) - những người bạn nhờ kiểm tra thay đổi. Quy tắc repository quyết định việc phê duyệt có bắt buộc hay không;
4. người phụ trách (Assignees) - thường bạn chọn chính mình làm tác giả và người chịu trách nhiệm chỉnh sửa sau khi nhận review.

Trước khi nhấn Create Pull Request, hãy kiểm tra lại base, head và diff. Nếu phần việc chưa sẵn sàng để review, bạn có thể tạo Draft PR khi tùy chọn này có sẵn. Cả PR thông thường lẫn bản nháp đều hiển thị với những người có quyền truy cập repository.

Code review - kiểm tra và thảo luận

Sau khi tạo PR, giai đoạn quan trọng nhất bắt đầu: code review. Đồng nghiệp có thể mở PR, xem tất cả thay đổi và để lại nhận xét.

Mọi cuộc thảo luận đều hiển thị ngay trong IDE, ở tab Pull Requests. Nếu có người bình luận vào một dòng mã, bạn sẽ nhận được thông báo và có thể trả lời mà không cần chuyển sang trình duyệt.

Nếu được yêu cầu chỉnh sửa thì sao? Rất đơn giản: bạn không cần tạo PR mới. Hãy sửa mã trên branch nguồn của PR này, tạo commit mới rồi push lên. Pull Request trên GitHub sẽ tự cập nhật và thêm commit mới vào cuộc thảo luận hiện có.

Hoàn tất công việc - merge và xóa branch

Khi đã xử lý mọi nhận xét và nhóm phê duyệt thay đổi (bạn nhận được "approval"), có thể merge Pull Request. Thường thì nhà phát triển cấp cao sẽ làm việc này, hoặc bạn tự thực hiện nếu có quyền trong repository.

Bước 1. Merge. Kiểm tra nhận xét, các phê duyệt bắt buộc và trạng thái kiểm tra. Nếu quy tắc và quyền truy cập cho phép merge, hãy chọn một phương thức khả dụng (merge, squash hoặc rebase) theo quy tắc của dự án rồi xác nhận. Thay đổi sẽ được đưa vào branch đích của PR, trong ví dụ này là main.

Bước 2. Xóa branch. Sau khi merge, feature branch không còn cần thiết. Bạn nên xóa nó để repository gọn gàng. GitHub sẽ đề xuất thao tác này qua nút Delete branch.

Sau khi merge, hãy chuyển sang main ở máy cục bộ, lấy các bản cập nhật và xác nhận kết quả PR đã có ở đó. Tiếp theo, bạn có thể xóa branch công việc cục bộ nếu không còn phần việc nào cần giữ. Nếu IDE không cho xóa theo cách thông thường, trước tiên hãy tìm hiểu nguyên nhân, nhất là sau khi squash hoặc rebase.

Ba quy tắc để có commit tốt

Commit tốt không chỉ cần thông điệp phù hợp mà còn phải chứa đúng phần việc. Để lịch sử thay đổi rõ ràng và hữu ích, hãy tuân theo ba quy tắc đơn giản.

Quy tắc 1 - viết thông điệp rõ ràng

Commit là thông điệp gửi cho nhóm và cho chính bạn trong tương lai. Lịch sử chỉ toàn "fix" hoặc "update" thì chẳng có ích gì. Một định dạng phổ biến là Conventional Commits, với cấu trúc như sau:

<loại>: <mô tả ngắn>

Loại là một từ ngắn cho biết thay đổi thuộc nhóm nào:

• feat - tính năng mới;
• fix - sửa lỗi;
• docs - thay đổi tài liệu;
• style - chỉnh sửa định dạng, không ảnh hưởng đến logic;
• refactor - thay đổi mã nhưng không thêm tính năng hay sửa lỗi;
• test - thêm hoặc sửa kiểm thử;
• chore - công việc thường ngày (cập nhật dependency, cấu hình build).

Ví dụ:

• Chưa tốt: fixed bug
• Tốt: fix: Correct user login validation
• Chưa tốt: readme
• Tốt: docs: Update installation instructions

Quy tắc 2 - một commit, một thay đổi logic

Đừng gộp sửa lỗi, tính năng mới và refactor mã cũ vào cùng một commit. Commit như vậy khó review và gần như không thể revert một cách an toàn. Mỗi commit nên giải quyết một việc cụ thể.

• Chưa tốt: một commit "Update user page" vừa thêm trường ảnh đại diện, vừa sửa phần kiểm tra tên, vừa đổi màu nút;
• Tốt: ba commit riêng:
  1. feat: Add avatar upload to user profile
  2. fix: Correct username validation logic
  3. feat: Update button colors on user page

Nếu trong lúc làm bạn thay đổi quá nhiều chỗ trong một tệp, IDE cho phép commit từng phần thay vì cả tệp: trong cửa sổ Commit, hãy mở rộng tệp và chỉ đánh dấu những phần (chunks) thuộc về công việc cụ thể.

Quy tắc 3 - kiểm tra kết quả thay đổi

Trước khi merge, hãy chạy các kiểm tra phù hợp với thay đổi và xem kết quả thực tế. Chỉnh sửa tài liệu và thêm logic mới cần những bộ kiểm tra khác nhau.

Nếu repository đã cấu hình kiểm tra tự động, PR sẽ hiển thị trạng thái của chúng. Dấu tích xanh lá cho biết các kiểm tra đã chạy đều thành công, chứ không chứng minh rằng mã không có lỗi. Hãy xem những gì đã chạy và phần nào chưa được kiểm tra. Cấu hình tự động hóa là chủ đề riêng.

Cách Claude Code hỗ trợ quy trình này

PR là nơi Claude Code đặc biệt hữu ích. Bạn nên chú ý những điểm sau:

• Claude có thể tạo pull request từ branch của bạn với tiêu đề và mô tả đã soạn sẵn; bạn kiểm tra nội dung trước khi tạo PR trên GitHub;
• có thể xem các thay đổi trong PR và để lại nhận xét như một lượt kiểm tra ban đầu;
• giúp viết thông điệp commit theo quy tắc của dự án;
• có thể giúp đọc kết quả của các kiểm tra đã cấu hình và chỉ ra phần chưa được kiểm tra.

Bài viết trước: Branch và merge trong Git · Bài viết tiếp theo: Hoàn tác và khôi phục thay đổi trong Git