TẤT CẢ Pull Request và quy trình cộng tác trên GitHub

Pull Request và quy trình cộng tác trên GitHub

SEO 100/100 A+

📚 Git & GitHub Series (Bài 9/15) — Đã biết đồng bộ ở Bài 8, giờ ta học trái tim của cộng tác GitHub: Pull Request.

Pull Request (thường gọi tắt là PR) là tính năng làm nên tên tuổi GitHub. Thay vì đẩy thẳng code vào nhánh chính, bạn mở một PR để đề xuất thay đổi, để người khác xem diff, góp ý, và để hệ thống tự động kiểm tra (CI) chạy — rồi mới gộp. Bài này hướng dẫn tạo PR, review code, và quy trình fork để đóng góp mã nguồn mở.

Pull Request là gì và vì sao quan trọng?

Theo tài liệu GitHub về Pull Request, PR là yêu cầu gộp commit từ một nhánh (nhánh nguồn) vào một nhánh khác (thường là main). Giá trị của nó không chỉ là "gộp", mà là cả một không gian cộng tác:

  • Hiển thị diff rõ ràng giữa hai nhánh.
  • Cho phép review từng dòng và để lại bình luận.
  • Tự động chạy CI/CD (kiểm thử, build) trước khi merge — chủ đề Bài 14.
  • Lưu lại lý do và lịch sử thảo luận của mỗi thay đổi.

Blog này áp dụng đúng nguyên tắc đó: mọi thay đổi đều qua PR, không push thẳng main.

Quy trình tạo Pull Request cơ bản

Giả sử bạn đã làm việc trên một nhánh tính năng (từ Bài 4):

git switch -c feature/them-trang-gioi-thieu
git add .
git commit -m "Thêm trang giới thiệu"
git push -u origin feature/them-trang-gioi-thieu

Sau khi push, GitHub hiện nút Compare & pull request. Bấm vào, viết tiêu đề và mô tả rõ ràng (làm gì, vì sao, cách kiểm tra), rồi bấm Create pull request.

Viết mô tả PR tốt

PhầnNội dung nên có
Tiêu đềNgắn gọn, kiểu feat: thêm trang giới thiệu
Mô tảThay đổi gì và vì sao
Cách testCác bước để người review kiểm chứng
Ảnh chụpVới thay đổi giao diện (nếu có)

Mô tả tốt giúp người review hiểu nhanh và duyệt sớm hơn.

Review code — văn hóa cộng tác

Khi review một PR, bạn có thể:

  • Bình luận trên từng dòng cụ thể.
  • Đề xuất chỉnh sửa trực tiếp (suggestion).
  • Chọn Approve, Request changes, hoặc Comment.

Review tốt nên cụ thể, tôn trọng, tập trung vào code chứ không vào người. Đây là kỹ năng mềm quan trọng ngang với kỹ năng kỹ thuật.

Ba cách gộp Pull Request

Khi PR được duyệt, GitHub cho ba lựa chọn merge:

  • Create a merge commit — giữ nguyên mọi commit và thêm một merge commit.
  • Squash and merge — gộp tất cả commit của PR thành một, lịch sử main gọn gàng.
  • Rebase and merge — đưa từng commit lên thẳng main, không tạo merge commit.

Với blog cá nhân hoặc dự án nhỏ, squash thường gọn nhất. Khái niệm rebase sẽ được làm rõ ở Bài 10.

Fork và đóng góp mã nguồn mở

Khi muốn đóng góp cho dự án bạn không có quyền ghi:

  1. Fork repo về tài khoản của bạn (nút Fork trên GitHub).
  2. Clone bản fork về máy, thêm remote upstream trỏ repo gốc (nhắc lại Bài 6).
  3. Tạo nhánh, commit, push lên fork.
  4. Mở PR từ fork của bạn tới repo gốc.

Đây chính là cách hàng triệu người đóng góp cho mã nguồn mở mỗi ngày.

Tóm lại

Pull Request biến Git từ công cụ cá nhân thành nền tảng cộng tác: bạn đề xuất thay đổi qua nhánh, người khác review diff, CI kiểm tra tự động, rồi mới merge. Nắm PR và quy trình fork là bạn đã sẵn sàng làm việc nhóm và đóng góp mã nguồn mở chuyên nghiệp.

Từ bài sau, series bước sang phần nâng cao. Bài 10 mở đầu với git rebase — làm sạch lịch sử commit, một công cụ mạnh nhưng cần dùng đúng cách.

Tham khảo & Nguồn dữ liệu

1. Liên kết bên ngoài được sử dụng trong bài viết

2. Liên kết nội bộ liên quan

3. Bản quyền & Ghi nguồn

Một phần dữ liệu trong bài viết được tham khảo từ tài liệu GitHub về Pull Request. Mọi thương hiệu, tên sản phẩm và tài liệu gốc thuộc quyền sở hữu của chủ sở hữu tương ứng. Bài viết chỉ trích dẫn, tổng hợp và phân tích — không nhằm thay thế tài liệu chính thức.

Câu hỏi thường gặp

Pull Request là gì?
Pull Request (PR) là đề xuất gộp các thay đổi từ một nhánh vào nhánh khác trên GitHub. Nó là nơi đồng đội xem diff, thảo luận, review code và chạy CI trước khi merge — trái tim của quy trình cộng tác hiện đại.
Fork khác clone thế nào?
Clone tạo bản sao repo về máy bạn. Fork tạo một bản sao repo trên tài khoản GitHub của bạn từ repo của người khác — dùng khi bạn muốn đóng góp cho dự án mà không có quyền ghi trực tiếp.
Nên dùng squash, merge hay rebase khi gộp PR?
Squash gộp mọi commit của PR thành một, cho lịch sử gọn. Merge commit giữ nguyên lịch sử và thêm điểm gộp. Rebase đưa commit lên thẳng main không tạo merge commit. Tùy quy ước nhóm; squash phổ biến cho blog/cá nhân.

💬 BÌNH LUẬN

Đăng nhập GitHub để comment. Hỗ trợ markdown, reaction, reply.

S-DNA · CI/CD Monitor

Live TheoDoi8

🔄 running
theodoi8@github-actions

Đang tải terminal theodoi8…