Hướng dẫn · 24/09/2026

Git bisect: Tìm commit gây lỗi bằng quy trình kiểm thử rõ ràng

Một tính năng vẫn chạy ở bản phát hành trước nhưng bị lỗi ở bản hiện tại. Giữa hai bản có hàng chục commit, và đọc từng diff chưa cho thấy nguyên nhân. Git bisect giúp thu hẹp phạm vi bằng cách kiểm tra các phiên bản trung gian thay vì đoán commit đáng nghi.

Git bisect: Tìm commit gây lỗi bằng quy trình kiểm thử rõ ràng

Một tính năng vẫn chạy ở bản phát hành trước nhưng bị lỗi ở bản hiện tại. Giữa hai bản có hàng chục commit, và đọc từng diff chưa cho thấy nguyên nhân. Git bisect giúp thu hẹp phạm vi bằng cách kiểm tra các phiên bản trung gian thay vì đoán commit đáng nghi.

Bài viết hướng dẫn quy trình điều tra trên bản sao repository dùng riêng cho kiểm thử. Các tên phiên bản bên dưới là ví dụ; không chạy lệnh chuyển commit trên thư mục đang phục vụ production hoặc chứa công việc chưa lưu.

1. Chuẩn bị một tiêu chí lỗi đủ rõ

Trước khi dùng công cụ, viết một mô tả có thể lặp lại: đầu vào nào, thao tác nào, kết quả kỳ vọng và kết quả thực tế. “Trang thỉnh thoảng chậm” chưa đủ tốt; một bài test nhỏ tái hiện cùng lỗi sẽ giúp mỗi lần phân loại đáng tin cậy hơn.

Đề xuất: dùng cùng bộ dữ liệu thử, ghi phiên bản runtime, tắt tác vụ nền không liên quan và không gọi dịch vụ có tác dụng thật như gửi email hay thanh toán. Chạy lại ca kiểm tra vài lần ở hai đầu mút để phát hiện test không ổn định trước khi bắt đầu.

2. Chọn một mốc tốt và một mốc lỗi

Pro Git trình bày bisect như cách thu hẹp lịch sử dựa trên kết quả tốt/xấu. Cần một commit cũ đã xác minh không có lỗi và một commit mới có lỗi. “Đã deploy được” không đồng nghĩa “đã vượt qua đúng ca kiểm tra này”.

git status --short
git bisect start
git bisect bad release-broken
git bisect good release-working

Thay release-brokenrelease-working bằng tag hoặc hash thật đã kiểm tra, với mốc tốt nằm trước lỗi trong lịch sử đang xét. Nếu status có thay đổi chưa xử lý, dừng và bảo vệ công việc trước; không dùng reset hard để làm sạch cho nhanh.

3. Kiểm tra phiên bản Git chọn

Sau khi xác định hai đầu mút, Git chuyển tới một commit trung gian. Dựng môi trường phù hợp commit đó, chạy ca tái hiện, rồi chỉ chọn một lệnh tương ứng:

git bisect good
# OR
git bisect bad
# OR, when this revision cannot be tested:
git bisect skip

Theo tài liệu git-bisect, skip dành cho phiên bản không thể đánh giá; các commit bị bỏ qua có thể khiến kết quả không xác định được một thủ phạm duy nhất. Không đánh dấu bad chỉ vì dependency cũ không cài được nếu đó không phải lỗi đang điều tra.

Ghi ngắn gọn hash, kết quả và lý do skip. Với lịch sử lỗi xuất hiện, được sửa rồi tái xuất hiện, hãy thu hẹp giai đoạn trước; không coi mọi kết quả tốt/xấu là một ranh giới đơn giản nếu chính hành vi thay đổi nhiều lần.

4. Tự động hóa sau khi test đã ổn định

Có thể dùng git bisect run với script kiểm tra riêng. Quy ước exit code: 0 là tốt; 1–127, trừ 125, là xấu; 125 là bỏ qua; mã ngoài khoảng đó khiến quá trình dừng. Vì vậy, lỗi gọi nhầm lệnh có thể bị phân loại thành lỗi sản phẩm nếu wrapper không phân biệt nguyên nhân.

git bisect run /absolute/path/to/check-regression.sh

Đường dẫn trên là placeholder cho script do dự án chuẩn bị, không phải script có sẵn. Giữ công cụ kiểm tra ngoài cây mã đang đổi commit nếu cần, đồng thời bảo đảm nó hiểu các phiên bản cũ. Script nên tách lỗi môi trường khỏi việc tái hiện đúng regression; không biến tất cả lỗi thành skip vì có thể che mất bằng chứng.

5. Xác nhận kết quả rồi kết thúc phiên

Khi tìm ra commit nghi vấn, đọc diff, chạy lại test ở commit đó và phiên bản trước phù hợp. Với merge commit, xem các parent và bối cảnh hợp nhất; không mặc định cứ parent đầu tiên là đủ giải thích lỗi.

git show --stat
git show
git bisect log
git bisect reset

Lưu kết quả log vào hồ sơ điều tra trước khi reset. Lệnh cuối kết thúc trạng thái bisect và đưa về HEAD ban đầu theo quy trình thông thường; nó không hoàn tác thay đổi database hay dịch vụ ngoài Git do test tạo ra.

6. Checklist để không kết luận sai

  • Hai đầu mút được kiểm tra bằng cùng tiêu chí nghiệp vụ.
  • Test không phụ thuộc thời gian, mạng hoặc dữ liệu biến động ngoài kiểm soát.
  • Dependency và cấu hình được dựng theo từng phiên bản.
  • Không đánh đồng lỗi môi trường với regression.
  • Commit tìm được được xác minh lại trước khi sửa hoặc revert.
  • Bổ sung regression test vào quy trình kiểm thử sau khi sửa.

Git bisect thu hẹp nơi hành vi thay đổi, không tự giải thích nguyên nhân gốc. Giá trị lớn nhất đến từ việc kết hợp công cụ với một ca tái hiện rõ ràng và bằng chứng kiểm thử nhất quán.

Thảo luận

Bình luận 0

Đăng nhập để bình luận

Bạn cần có tài khoản để tham gia thảo luận và trả lời độc giả khác.

Đăng nhậpĐăng ký

Chưa có bình luận. Hãy là người đầu tiên chia sẻ ý kiến.