← Lập trình với Claude Code

Bài 12 · Vận dụng · 20 phút· Cập nhật 13/07/2026

Quy trình: nhánh → PR → review

Biên soạn bởi Nguyễn Anh Tuấn

Quy trình git khi lập trình với AI: làm trên nhánh, commit sạch, mở pull request (PR), review cùng Claude; gh CLI và GitHub Actions.

Claude sửa nhiều file rất nhanh - đó là lý do bạn càng cần một lưới an toàn. Quy trình kinh điển: làm trên một nhánh riêng → commit gọn → PRreview → mới gộp vào main. Đây chính là “kiểm chứng” ở cấp quy trình.

  • Nhánh riêng = main luôn sạch; sai thì bỏ nhánh, không ảnh hưởng gì.
  • PR gom toàn bộ thay đổi để bạn xem & duyệt một lần, có lịch sử.
  • Con người review trước khi merge - AI đề xuất, bạn quyết định.

git chỉ là lệnh shell, nên Claude dùng Bash để tạo nhánh và commit (vẫn xin phép theo chế độ quyền). Hãy yêu cầu commit gọn theo từng phần với thông điệp rõ:

claude - ~/cua-hang-x

Tạo nhánh cho thay đổi này, commit gọn rồi mở PR.

Bash(git checkout -b feat/logout-button)

Bash(git commit -m "feat(header): thêm nút Đăng xuất")

Bash(gh pr create --title "Thêm nút Đăng xuất" --body "...")

✓ PR #142 đã mở

Đã mở PR #142. Bạn xem diff trên GitHub và duyệt nhé - tôi không tự merge.

  • Một nhánh cho một việc; tên nhánh gợi nội dung (feat/…, fix/…).
  • Commit nhỏ, mỗi commit một ý; thông điệp nói RÕ thay đổi gì & vì sao.
  • Ghi quy ước commit vào CLAUDE.md để Claude theo đúng kiểu nhóm (xem bài CLAUDE.md).

Claude mở PR bằng gh (GitHub CLI) và tự viết mô tả từ các thay đổi. Mẹo hay: nhờ Claude tự review PR của chính nó trước, rồi bạn review lần cuối:

  • gh pr create: Claude tạo PR kèm tiêu đề + mô tả từ diff.
  • Nhờ Claude “tự tìm lỗi/điểm yếu trong PR này” - thêm một lượt soát vẫn hơn.
  • Bạn đọc diff lần cuối: đúng ý? có đụng nhầm? có thiếu test?

Bật những thực hành bạn sẽ làm - xem ngay PR của bạn ở mức độ sẵn sàng nào:

Bật những thực hành bạn đã làm trước khi tạo PR - mô-đun tính mức độ sẵn sàng:

Điểm sẵn sàng 0/100 - Rủi ro

Cần chú ý (6)

  • ⚠ Đang làm thẳng trên main - sai thì không gỡ được.
  • ⚠ Test chưa xanh - code có thể hỏng chức năng đang chạy.
  • ⚠ Chưa đọc diff - mèo con là người chịu trách nhiệm cuối.
  • ⚠ Commit lớn khó review và khó revert khi có vấn đề.
  • ⚠ Thiếu mô tả PR - reviewer (kể cả bạn sau này) không biết thay đổi làm gì.
  • ⚠ Để AI tự merge là mất quyền kiểm soát cuối cùng.

Một PR = một việc gọn

PR nhỏ thì dễ review, dễ phát hiện lỗi, dễ revert. Nếu việc lớn, để Claude chia nhỏ thành nhiều PR - đừng dồn cả ngàn dòng vào một chỗ.

Bạn còn dùng được Claude ngay trên GitHub. Trong terminal, gõ /install-github-app - nó cài Claude GitHub app, tạo file workflow và thêm secret ANTHROPIC_API_KEY. Sau đó chỉ cần mention @claude trong issue/PR:

bình luận trong issue hoặc PR

@claude triển khai tính năng theo mô tả trong issue này
@claude sửa lỗi TypeError ở trang dashboard
@claude xem PR này có vấn đề bảo mật nào không?

.github/workflows/claude.yml - rút gọn

name: Claude Code
on:
  issue_comment:
    types: [created]
  pull_request_review_comment:
    types: [created]
jobs:
  claude:
    runs-on: ubuntu-latest
    steps:
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
  • /install-github-app: cài app + workflow + secret - chỉ admin repo làm được.
  • @claude trong issue/PR: Claude triển khai issue, sửa bug, trả lời bình luận review.
  • Chạy trên máy của GitHub (Actions); vẫn tôn trọng CLAUDE.md của repo.
  • CON NGƯỜI duyệt trước khi merge - đừng để AI tự gộp vào main.
  • Bảo vệ nhánh main: yêu cầu review và CI xanh trước khi merge.
  • Bí mật để trong GitHub Secrets (vd ANTHROPIC_API_KEY) - KHÔNG commit vào code.
  • Đọc diff của AI như đọc PR của đồng nghiệp: tin nhưng phải kiểm.

Tiếp theo: Review code AI sinh ra

Quy trình git là lưới an toàn. Bài kế đi vào phần quan trọng nhất khi AI sinh nhiều code nhanh hơn tốc độ đọc của bạn: chiến lược review code AI sinh ra, để con người vẫn là điểm chốt chất lượng trước khi merge.

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

Chính VÌ Claude sửa nhiều file rất nhanh nên bạn càng cần lưới an toàn. Làm trên một NHÁNH riêng nghĩa là nhánh chính (main) luôn sạch; bạn xem toàn bộ thay đổi gộp lại trong một PR, duyệt, rồi mới merge. Sai thì bỏ nhánh, main không hề hấn. Đây là “kiểm chứng” ở cấp quy trình.

Được - git chỉ là lệnh shell, Claude dùng công cụ Bash để tạo nhánh, commit, push (vẫn xin phép theo chế độ quyền của bạn). Bạn có thể nhờ “tạo nhánh feature/x, commit gọn theo từng phần”. Ghi quy ước commit vào CLAUDE.md để nó theo đúng kiểu của nhóm.

Bài CLAUDE.md & bộ nhớ dự án →

Claude thường dùng gh (GitHub CLI): gh pr create. Nó có thể viết tiêu đề + mô tả PR từ các thay đổi. Bạn xem PR trên GitHub, đọc diff, bình luận, rồi merge khi ưng. Quy ước: một PR = một việc gọn, dễ review.

/install-github-app trong terminal để cài Claude GitHub app + tạo file workflow trong .github/workflows/ + thêm secret ANTHROPIC_API_KEY. Sau đó, trong issue hay PR, bạn mention @claude là Claude tự phân tích và hành động (triển khai issue, sửa bug, trả lời bình luận review) ngay trên GitHub.

Cùng “bộ não”, khác nơi chạy: @claude chạy trên GitHub Actions (máy của GitHub), hợp cho việc tự động hoá theo sự kiện (có issue mới, có PR). Còn Claude Code ở máy bạn hợp cho phát triển tương tác. Cả hai đều tôn trọng CLAUDE.md của repo.

KHÔNG. Để AI mở PR và đề xuất, nhưng việc GỘP vào main nên do CON NGƯỜI quyết sau khi review. Bảo vệ nhánh main (yêu cầu review/CI xanh trước khi merge). AI tăng tốc, nhưng trách nhiệm cuối là của bạn.

Tick những điều em tự tin làm được. Càng lên cao, em càng hiểu sâu.

Tick những điều em tự tin làm được sau khi học bài này. 0/6

Trả lời vài câu để chắc rằng em đã nắm bài.

Câu 1/3 Điểm: 0

Vì sao càng nên làm trên nhánh + PR khi để Claude sửa code?

  1. 1

    Một việc, một nhánh

    Nhờ Claude tạo một nhánh mới cho một thay đổi nhỏ, thực hiện, rồi commit gọn với thông điệp rõ ràng.

    Hoàn thành khi: Có một nhánh riêng với 1-2 commit message mô tả đúng thay đổi; main không bị đụng.

  2. 2

    Mở PR

    Để Claude mở PR bằng gh pr create với tiêu đề + mô tả. Mở PR trên GitHub và đọc diff.

    Hoàn thành khi: Một PR tồn tại với mô tả hợp lý; bạn đọc qua toàn bộ diff trước khi nghĩ tới merge.

  3. 3

    Review hai vòng

    Nhờ Claude TỰ review PR của chính nó (tìm lỗi/điểm yếu), rồi BẠN tự review lần nữa.

    Hoàn thành khi: Có nhận xét từ Claude + đánh giá của bạn; bạn quyết định sửa gì trước khi merge.

  4. 4

    Ghi quy ước commit

    Thêm vào CLAUDE.md quy ước commit của bạn (vd Conventional Commits) để Claude theo đúng.

    Hoàn thành khi: Lần commit sau, Claude viết message đúng kiểu bạn đã ghi - không phải nhắc lại.

  5. 5

    Thử @claude (tùy chọn)

    Trên một repo bạn có quyền admin, chạy /install-github-app, rồi mở một issue và mention @claude nhờ một việc nhỏ.

    Hoàn thành khi: Claude phản hồi trên GitHub (bình luận hoặc mở PR); bạn thấy nó tôn trọng CLAUDE.md của repo.