Git, GitHub CLI và CI là những nơi Claude Code giúp bạn tiết kiệm thời gian rõ rệt nhất. Phần lớn công việc ở đây chỉ xoay quanh gõ lệnh, đọc log và chờ kết quả, đúng những việc một tác nhân có thể làm thay bạn.
Đây là phần sáu trong loạt bài giới thiệu 50 mẹo Claude Code từ repo claude-code-tips của YK Sugi. Phần này tập hợp sáu mẹo về Git, GitHub và vận hành, gồm các mẹo số 4, 13, 14, 15, 36 và 27. Các mẹo đi từ công việc nhỏ nhất, như tạo một commit, đến việc tốn thời gian nhất, chẳng hạn điều tra một lần CI báo lỗi mà chưa rõ nguyên nhân.
Nguyên tắc xuyên suốt là để Claude lo những việc tay chân, còn bạn kiểm soát các bước có rủi ro cao như push và merge.
Nên giao cho Claude những việc gì với Git và GitHub CLI?
Bạn có thể bảo Claude tạo commit mà không cần tự viết commit message, tạo nhánh, pull hoặc push. Cách phân quyền hợp lý là cho phép Claude tự động pull nhưng không tự động push, vì push có rủi ro cao hơn. Nếu pull gặp trục trặc, ít nhất bạn cũng không làm ảnh hưởng đến origin.
Với GitHub CLI (gh), một thói quen rất đáng áp dụng là tạo draft PR. Claude có thể lo toàn bộ quá trình tạo PR vì đây là công việc ít rủi ro, còn bạn kiểm tra lại mọi thứ trước khi chuyển PR sang trạng thái sẵn sàng review. gh cũng mạnh hơn nhiều người nghĩ, vì nó cho phép gửi các truy vấn GraphQL tùy ý. Chẳng hạn, nếu muốn biết chính xác mô tả của một PR đã được chỉnh sửa vào những thời điểm nào, bạn có thể chạy:
gh api graphql -f query='
query {
repository(owner: "...", name: "...") {
pullRequest(number: ...) {
userContentEdits(first: 100) {
nodes { editedAt editor { login } }
}
}
}
}'Claude chạy lệnh này rồi trả về bảng lịch sử chỉnh sửa, mỗi dòng tương ứng với một lần sửa, kèm thời gian và người thực hiện. Bạn không cần thuộc schema GraphQL của GitHub, chỉ cần mô tả thông tin mình muốn tìm là đủ.
Làm sao để bỏ dòng ghi công Claude trong commit và PR?
Theo mặc định, Claude Code thêm trailer Co-Authored-By vào commit và một dòng ghi công (attribution) ở cuối mô tả PR. Nếu muốn bỏ cả hai, bạn thêm khối cấu hình sau vào ~/.claude/settings.json:
{
"attribution": {
"commit": "",
"pr": "",
"sessionUrl": false
}
}Đặt commit và pr thành chuỗi rỗng để xóa hoàn toàn phần ghi công. Cấu hình này thay thế includeCoAuthoredBy cũ, một tùy chọn hiện đã bị đánh dấu ngừng sử dụng.
Riêng sessionUrl là một cờ độc lập, mặc định có giá trị true. Khi bạn commit hoặc mở PR từ một phiên cloud hay Remote Control, Claude Code sẽ thêm trailer Claude-Session vào commit và chèn đường link phiên vào mô tả PR. Đặt giá trị này thành false để bỏ đường link đó. Mỗi đội có thể chọn bật hoặc tắt tùy nhu cầu, miễn là bạn biết các khóa cấu hình này tồn tại.
Làm sao chạy nhiều phiên Claude Code cùng lúc mà không bị rối?
Khi chạy nhiều phiên Claude Code, giữ mọi thứ ngăn nắp còn quan trọng hơn bất kỳ thiết lập kỹ thuật nào, kể cả git worktree. Lời khuyên của tôi là chỉ nên tập trung vào tối đa ba hoặc bốn việc cùng lúc.
Repo gọi cách tổ chức tab này là "thác nước" (cascade): mỗi khi bắt đầu việc mới, bạn mở một tab mới ở bên phải. Sau đó, cứ quét các tab từ trái sang phải, từ việc cũ nhất đến việc mới nhất, rồi lặp lại. Bạn luôn giữ hướng di chuyển này, trừ khi cần kiểm tra một việc cụ thể hoặc có thông báo mới.
Ví dụ, tab ngoài cùng bên trái có thể chạy hệ thống chép giọng nói, tab thứ hai dựng một container Docker, tab thứ ba kiểm tra dung lượng ổ cứng, tab thứ tư xử lý một dự án kỹ thuật, còn tab thứ năm (đang mở) dùng để viết chính mẹo này. Nghe thì đơn giản, nhưng theo tôi, giới hạn "ba bốn việc" mới là phần khó thực hiện nhất. Mở thêm tab rất dễ, còn nhớ tab nào đang chờ mình xử lý thì khó hơn nhiều.
Git worktree giúp làm việc song song như thế nào?
Nếu muốn xử lý nhiều việc trên cùng một dự án mà không để chúng ảnh hưởng lẫn nhau, git worktree là lựa chọn tốt. Bạn chỉ cần bảo Claude Code tạo một git worktree rồi làm việc trong đó, không cần nhớ cú pháp. Hiểu đơn giản, mỗi worktree gồm một nhánh và một thư mục riêng.
Không dùng worktree thì thư mục dự án chỉ có thể làm việc trên một nhánh tại một thời điểm. Vì vậy, bạn phải lần lượt chuyển giữa main và feature-branch-1. Còn khi dùng worktree, bạn có thể tiếp tục làm việc trên main hoặc bất kỳ nhánh nào trong thư mục gốc, đồng thời xử lý feature-branch-1 trong một thư mục mới.
Worktree bổ sung cho cách tổ chức "thác nước" ở trên: mỗi tab phụ trách một việc, còn mỗi việc có chỉnh sửa code nên có worktree riêng. Bạn cũng có thể áp dụng mẹo ở phần ba, bảo Claude mở worktree đó trong GitHub Desktop để xem các thay đổi, vì thường bạn chưa mở Claude Code tại thư mục mới.
Làm sao chờ job chạy lâu bằng exponential backoff thủ công?
Khi phải chờ những job chạy lâu, chẳng hạn build Docker hoặc CI trên GitHub, hãy bảo Claude Code kiểm tra trạng thái theo các khoảng nghỉ tăng dần: một phút, rồi hai phút, rồi bốn phút, cứ thế tiếp tục. Exponential backoff (tăng khoảng nghỉ theo cấp số nhân) vốn là kỹ thuật quen thuộc trong lập trình. Điểm khác biệt ở đây là AI thực hiện thủ công thay vì chạy một đoạn code, và cách này hoạt động khá ổn. Tác nhân sẽ tiếp tục kiểm tra rồi báo bạn khi job hoàn tất.
Với GitHub CI, bạn có thể dùng gh run watch, nhưng lệnh này liên tục in ra rất nhiều dòng, gây lãng phí token. Thay vào đó, kiểm tra thủ công theo kiểu backoff sẽ tiết kiệm token hơn:
gh run view <run-id> | grep <job-name>Bạn cũng có thể áp dụng cách này ở bất kỳ nơi nào không có sẵn lệnh chờ chuyên dụng. Mỗi lần kiểm tra chỉ tạo ra vài dòng output, thay vì để cả luồng log liên tục đổ vào context.
Làm sao chạy lệnh bash và subagent dưới nền?
Nếu một lệnh bash trong Claude Code chạy lâu hơn dự kiến, hãy nhấn Ctrl+B để chuyển lệnh sang chạy nền. Nếu dùng tmux, bạn cần nhấn hai lần vì Ctrl+B vốn là phím tiền tố của tmux. Claude Code có thể quản lý các tiến trình nền và đọc output của chúng sau đó. Trong lúc chờ, nó có thể dùng exponential backoff như ở mục trên để theo dõi tiến độ, hoặc chuyển sang làm một việc khác.
Claude Code cũng có thể chạy subagent (tác nhân phụ) dưới nền. Khi cần nghiên cứu trong thời gian dài hoặc muốn một tác nhân định kỳ kiểm tra điều gì đó, bạn không cần để nó chiếm tiền cảnh. Chỉ cần bảo Claude chạy tác nhân hoặc tác vụ đó dưới nền. Ngoài ra, subagent còn hữu ích khi cần chia nhỏ một công việc lớn. Chẳng hạn, với một codebase khổng lồ cần phân tích, bạn có thể yêu cầu Claude tạo nhiều subagent để phân tích theo những cách khác nhau hoặc mỗi subagent phụ trách một phần codebase, tất cả chạy song song.
Bạn có thể tùy chỉnh subagent chỉ bằng lời: số lượng cần chạy, chạy dưới nền hay ở tiền cảnh (bằng cách ra lệnh hoặc nhấn Ctrl+B), và model cần dùng (Fable, Opus, Sonnet hay Haiku tùy độ khó của từng phần). Nếu không chỉ định, subagent sẽ dùng cùng model với hội thoại chính. Vì vậy, với những việc đơn giản như quét file, chọn một model nhỏ hơn là cách tiết kiệm dễ áp dụng nhất.
Làm sao dùng Claude Code như một kỹ sư DevOps?
Mẹo này đáng được tách riêng vì hiệu quả rất rõ rệt. Mỗi khi CI trên GitHub Actions báo lỗi, hãy gửi link cho Claude Code và yêu cầu: "dig into this issue, try to find the root cause" (điều tra vấn đề này và tìm nguyên nhân gốc). Đôi khi câu trả lời đầu tiên còn hời hợt, nhưng bạn có thể hỏi tiếp xem lỗi bắt nguồn từ một commit cụ thể, một PR cụ thể hay chỉ là lỗi chập chờn (flaky). Tự lần mò qua hàng đống log rất mất công, còn Claude Code có thể xử lý phần lớn công việc đó giúp bạn.
Bạn có thể đóng gói quy trình này thành slash command /gha. Chỉ cần chạy /gha <url> với bất kỳ URL GitHub Actions nào, Claude sẽ tự điều tra lỗi, kiểm tra xem có phải lỗi flaky không, tìm commit gây lỗi và đề xuất cách khắc phục. Skill này nằm trong thư mục skills/gha của repo hoặc có thể cài qua plugin dx.
Sau khi tìm ra nguyên nhân, bạn quay lại áp dụng các mẹo trước đó: tạo draft PR, kiểm tra output, để Claude tự kiểm chứng (phần năm), rồi mới chuyển PR sang trạng thái chính thức để sửa lỗi. Theo tôi, đây là một trong những cách Claude Code giúp đội nhỏ tiết kiệm thời gian nhanh nhất. Một lần CI báo lỗi có thể khiến cả đội mất nguyên buổi dò log, nhưng giờ bạn chỉ cần đặt vài câu hỏi.
Nên giao cho Claude bước nào trước?
Hãy bắt đầu với draft PR và /gha (hoặc prompt "find the root cause"), vì cả hai đều ít rủi ro. Claude xử lý công việc, còn bạn duyệt lại trước khi bất kỳ thứ gì đến tay người khác. Khi đã quen với việc theo dõi ba hoặc bốn đầu việc cùng lúc, bạn có thể tiếp tục với worktree, nhiều tab và subagent chạy nền.