Nhánh, Pull Request và review bằng Claude

Vì sao người làm một mình vẫn cần nhánh và PR, cách đọc phần thay đổi, và cách bắt AI tự review mã của chính nó.

Người làm một mình thường nghĩ nhánh và Pull Request là nghi thức của công ty lớn. Với Vibe Code thì ngược lại: chúng là cái phanh của bạn khi làm việc với một đồng nghiệp gõ nhanh gấp 50 lần mình.

Nhánh để làm gì, nói thật

Nhánh là một bản sao mã nguồn để bạn làm hỏng thoải mái, trong khi bản chính (main) vẫn lành.

Ba tình huống mà nhánh cứu bạn, đều rất thật:

1. Thử một tính năng chưa biết có nên giữ. Làm trên nhánh, không hay thì xóa nhánh, main chưa bao giờ biết tới nó.
2. Khách đang dùng bản hiện tại. Bạn không được phép để main hỏng giữa giờ làm việc của người ta.
3. Bạn cần một link preview để khách xem trước khi gật — Cloudflare Pages tự tạo link riêng cho mỗi nhánh.

Vòng làm việc đầy đủ

# 1. Bắt đầu từ main sạch
git checkout main
git pull

# 2. Tạo nhánh theo việc
git checkout -b bo-loc-thang

# 3. Làm việc (bạn + AI), commit theo từng bước nhỏ
git add . ; git commit -m "Them o chon thang va ham loc"
git add . ; git commit -m "Dong bo so dong tong voi ket qua loc"

# 4. Đẩy nhánh lên GitHub
git push -u origin bo-loc-thang

# 5. Mở Pull Request
gh pr create --fill

Đặt tên nhánh theo việc, không theo ngày: bo-loc-thang, sua-loi-luu-ten-co-dau, them-xuat-excel. Ba tuần sau bạn vẫn hiểu.

Pull Request là cái gì, với người làm một mình

PR là một trang web hiển thị toàn bộ khác biệt giữa nhánh của bạn và main, kèm chỗ để ghi chú và chỗ để bàn.

Dù chỉ có một mình, PR cho bạn ba thứ không thay được:

• Màn hình đọc thay đổi tử tế — xanh là thêm, đỏ là bớt, theo từng file. Dễ đọc hơn git diff rất nhiều khi thay đổi lớn.
• Một chỗ ghi lại vì sao. Lịch sử commit nói cái gì; phần mô tả PR nói vì sao — thứ mà ba tháng sau bạn sẽ cần.
• Cổng chặn. Có PR thì bạn không thể lỡ tay đẩy mã nửa vời vào main.

Mẫu mô tả PR dùng được ngay:

## Việc
Thêm bộ lọc theo tháng cho bảng đơn hàng.

## Vì sao
Chị kế toán phải tự cuộn tìm đơn trong tháng, mỗi lần mất ~3 phút,
ngày nào cũng làm 2 lần.

## Đã kiểm
- [x] Chọn tháng 9 → còn 42 dòng, khớp số ở dòng tổng
- [x] Chọn lại "Tất cả" → về 318 dòng như cũ
- [x] Trên điện thoại 375px: ô chọn không bị che, chữ không bẻ dòng
- [x] Console sạch lỗi
- [ ] CHƯA kiểm: dữ liệu năm trước (chưa có trong cơ sở dữ liệu)

## Rủi ro
Nếu đơn có ngày để trống thì bị lọc mất. Hiện chưa có đơn nào như vậy.

Mục "Đã kiểm" là mục làm nên giá trị của PR. Nó buộc bạn đi bấm thử thật, và nó chừa lại bằng chứng. Mục "CHƯA kiểm" cũng bắt buộc — bài test ở Cấp 5 sẽ nói rõ tại sao: một kết luận không nói rõ phần chưa kiểm là một kết luận không dùng được.

Gộp nhánh vào main

Khi PR đã ổn:

gh pr merge --squash --delete-branch

--squash gộp mọi commit của nhánh thành một mốc duy nhất trên main. Với người làm một mình, đây gần như luôn là lựa chọn đúng: main giữ được lịch sử gọn, mỗi mốc là một tính năng hoàn chỉnh, và nếu phải lùi thì lùi một lần là sạch.

Rồi về máy:

git checkout main
git pull

Bắt Claude review mã của chính nó

Đây là phần mạnh nhất của bài, và là thứ người làm một mình thiếu nhất: một người thứ hai đọc lại.

Đọc toàn bộ thay đổi của nhánh này so với main (git diff main...HEAD).
Review như một người khó tính, theo đúng thứ tự ưu tiên:

1. ĐÚNG SAI: có trường hợp nào cho kết quả sai không? Dữ liệu rỗng,
   dữ liệu null, ngày để trống, tên có dấu, số 0, số âm?
2. MẤT DỮ LIỆU: có đường nào ghi đè hoặc xóa mất dữ liệu cũ không?
3. PHÁ LUỒNG CŨ: có thay đổi hành vi mặc định mà tôi không yêu cầu không?
4. ĐƠN GIẢN HƠN: chỗ nào làm phức tạp quá mức cần thiết?

Với mỗi vấn đề: nói file và dòng, nói hậu quả cụ thể, nói cách sửa nhỏ nhất.
Nếu không có vấn đề thật thì nói "không có" — đừng bịa ra để có cái nói.

Câu cuối là câu bắt buộc. Thiếu nó, AI sẽ tìm ra "vấn đề" cho đủ lệ bộ, và bạn mất thời gian với những góp ý trang trí.