Cơ bảnKiến thức cơ bản

Pull Request là gì? Quy trình review code trên GitHub

8 phút đọc1 lượt xem
#pull request#github#code review#git#teamwork

Pull Request là gì?

Pull Request (viết tắt: PR) là yêu cầu gộp code từ nhánh này vào nhánh khác, thường đi kèm với quá trình review code. Nói đơn giản, PR giống như một "đề xuất": "Code này tôi viết xong rồi, mọi người kiểm tra giúp rồi gộp vào code chính nhé!"

Trong làm việc nhóm, không ai được phép sửa trực tiếp code chính (main). Mọi thay đổi đều phải qua Pull Request để đảm bảo chất lượng.

Ôn lại Git cơ bản tại Git là gì? và GitHub tại GitHub là gì?

Tại sao cần Pull Request?

Đảm bảo chất lượng code

Có người khác đọc và kiểm tra code giúp phát hiện bug sớm.

Chia sẻ kiến thức trong team

Qua review PR, các thành viên học hỏi lẫn nhau.

Theo dõi lịch sử thay đổi

Mỗi PR ghi lại: ai đổi gì, tại sao, ai review, ai approve.

Bảo vệ nhánh chính

Không ai push thẳng vào main — tất cả phải qua PR.

Quy trình tạo Pull Request

Bước 1 — Tạo branch mới

# Cập nhật main mới nhất
git checkout main
git pull origin main

# Tạo branch cho tính năng mới
git checkout -b feature/form-dang-ky

Quy tắc đặt tên branch:

  • feature/ten-tinh-nang — Tính năng mới
  • fix/ten-loi — Sửa lỗi
  • docs/ten-tai-lieu — Tài liệu

Bước 2 — Viết code và commit

git status
git add .
git commit -m "Thêm form đăng ký với validation email"

Bước 3 — Push lên GitHub

git push origin feature/form-dang-ky

Bước 4 — Tạo PR trên GitHub

  1. Mở repository trên GitHub
  2. Nhấn "Compare & pull request"
  3. Kiểm tra: Base: main ← Compare: feature/form-dang-ky
  4. Viết tiêu đề và mô tả
  5. Nhấn "Create Pull Request"

Bước 5 — Chỉ định reviewer

Chọn thành viên trong team ở mục "Reviewers" bên phải.

Cách viết mô tả PR tốt

## Mô tả
Thêm form đăng ký tài khoản mới với validation.

## Thay đổi
- Tạo component FormDangKy
- Thêm validation email và mật khẩu
- Kết nối API đăng ký

## Screenshot
(Đính kèm ảnh nếu thay đổi giao diện)

## Issue liên quan
Fixes #42

Quy trình review code

Vai trò Reviewer

  1. Đọc mô tả PR
  2. Xem tab "Files changed" — kiểm tra từng dòng code
  3. Comment góp ý trên từng dòng
  4. Chọn "Approve" (đồng ý) hoặc "Request changes" (yêu cầu sửa)

Vai trò tác giả PR

  1. Đọc comment của reviewer
  2. Sửa code theo góp ý, commit thêm
  3. Yêu cầu review lại

Văn hóa review code

  • Góp ý xây dựng: "Có thể thử cách này?" thay vì "Sai rồi!"
  • Giải thích lý do: Nói rõ tại sao cần thay đổi
  • Khen khi code tốt: "LGTM!" (Looks Good To Me)

PR được merge như thế nào?

1. Tạo branch → 2. Viết code → 3. Push → 4. Tạo PR
      ↓
5. Review → 6. Góp ý → 7. Sửa code
      ↓
8. Approve → 9. Merge → 10. Xóa branch

3 kiểu merge:

  • Merge commit — Giữ nguyên tất cả commit (mặc định)
  • Squash and merge — Gộp tất cả thành 1 commit
  • Rebase and merge — Giữ lịch sử tuyến tính

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

Hỏi: Làm một mình có cần dùng PR không?

Trả lời: Nên dùng. PR giúp bạn tự review lại code một cách khách quan.

Hỏi: PR nên dài bao nhiêu?

Trả lời: 200–400 dòng thay đổi là lý tưởng. PR quá lớn rất khó review.

Hỏi: Bị conflict thì làm sao?

Trả lời: Pull main mới nhất vào branch của bạn: git pull origin main, sau đó giải quyết conflict thủ công.

Bước tiếp theo

  1. Ôn Git cơ bảnGit là gì?
  2. Ôn GitHubGitHub là gì?
  3. Học lệnh GitCác lệnh Git cơ bản

Về tác giả

Ảnh đại diện tác giả Kenji — họa tiết hình học

Kenji

Kỹ sư phần mềm full-stack (Web), hơn 5 năm kinh nghiệm thực tế

  • Python
  • DB
  • Hạ tầng
  • Đào tạo & cố vấn
  • AI

Làm việc cùng đồng nghiệp người Việt, tôi thấy thiếu tài liệu kỹ thuật rõ ràng bằng tiếng Việt. codeahoc là nơi tôi chia sẻ theo hướng thực tế, dễ áp dụng.

Nguyên tắc nội dung

  • Ưu tiên nguồn gốc và góc nhìn từ thực tế triển khai.
  • Nếu có sai sót, nội dung sẽ được cập nhật và sửa kịp thời.
Quảng cáo