Git Bisect: Công cụ cứu cánh giúp tôi tìm ra lỗi code chỉ trong 20 phút

Hai tuần trước, một đồng nghiệp của tôi đã thực hiện gộp nhánh (merge) một tính năng mới vào chiều thứ Sáu. Đến sáng thứ Hai, một nửa bộ kiểm thử (test suite) của chúng tôi báo lỗi đỏ rực. Không ai biết chính xác commit nào đã gây ra sự cố, vì nhánh đó chứa tới 47 commit.

Tôi làm điều mà hầu hết các lập trình viên đều làm: mở git log, nhìn chằm chằm vào nó, rồi đóng lại. Bốn mươi bảy commit. Không có cách nào tôi có thể đọc hết tất cả chúng.

Vì thế, tôi đã làm điều mà một người bình thường sẽ làm: đổ lỗi cho tất cả mọi người trong lịch sử commit cho đến khi tìm được người để "giận". Đùa thôi, nhưng cũng gần đúng.

Cách tiếp cận thủ công

Lệnh git blame cho tôi biết những dòng nào đã thay đổi nhưng không nói tại sao chúng bị lỗi. git log hiển thị tên tệp nhưng không cho thấy thiệt hại thực tế. Tôi đã dành hai ngày để thu hẹp phạm vi thủ công. Checkout từng commit một. Chạy test. Xem chúng thất bại. Checkout cái khác. Chạy test. Xem chúng thất bại.

Cách tiếp cận của tôi mang tính khoa học, nhưng khoản đầu tư thời gian thì không.

# Điều tôi đang làm (cảnh báo: sai lầm)
git checkout commit-xyz
npm test  # 47 lần

Bốn mươi bảy lần. Với 3 phút cho mỗi lần chạy, đó là hơn hai giờ chỉ để chờ đợi. Chưa kể thời gian checkout và chi phí chuyển đổi ngữ cảnh (context switching).

Giới thiệu Git Bisect

Một lập trình viên cấp cao đi ngang qua, nhìn thấy màn hình của tôi và hỏi tại sao tôi không dùng git bisect.

Tôi không có câu trả lời nào thuyết phục.

git bisect thực hiện tìm kiếm nhị phân (binary search) trên lịch sử commit của bạn. Bạn chỉ cho nó một commit "tốt" đã biết và một commit "xấu" đã biết. Nó sẽ đưa bạn đến điểm giữa. Bạn kiểm thử. Bạn đánh dấu tốt hoặc xấu. Nó thu hẹp phạm vi. Lặp lại cho đến khi tìm ra thủ phạm.

# Bắt đầu cuộc săn lùng
git bisect start

# Đánh dấu HEAD hiện tại là xấu (bad)
git bisect bad

# Đánh dấu commit tốt cuối cùng đã biết
git bisect good v2.4.0

# Git sẽ đưa bạn đến điểm giữa
# Kiểm thử. Sau đó đánh dấu:
git bisect good  # test pass
git bisect bad   # test fail

Chỉ vậy thôi. Đó là toàn bộ quy trình làm việc.

Thay vì checkout thủ công 47 lần, tôi chỉ cần làm 6 lần. Sáu lần kiểm thử. Tôi đã tìm ra commit làm hỏng mọi thứ. Đó là một thay đổi cấu hình mà ai đó đã thực hiện lúc 11 giờ đêm. Họ đã thêm một trường bắt buộc vào xác thực người dùng nhưng quên cập nhật các dữ liệu kiểm thử (test fixtures).

Tổng thời gian: 20 phút.

Toán học của tìm kiếm nhị phân chính là lý do nó hoạt động nhanh đến vậy. Với N commit, bạn cần tối đa log2(N) lần kiểm thử. Bốn mươi bảy commit cần 6 lần kiểm thử thay vì 47 lần. Đó là sự khác biệt giữa một giờ chờ đợi và năm phút.

git bisect nghe có vẻ đáng sợ vì cụm từ "tìm kiếm nhị phân" nghe rất kỹ thuật. Nhưng thực tế không phải vậy. Bạn chạy hai lệnh để bắt đầu, sau đó một lệnh sau mỗi lần kiểm thử. Nó có sẵn trong git. Không cần cài đặt plugin nào cả.

# Dọn dẹp khi hoàn thành
git bisect reset