Cách phát hiện lỗi bằng git bisect

Cách tôi gỡ lỗi hầu như tất cả các vấn đề liên quan đến lịch sử thay đổi lâu dài, được theo dõi bằng Git và khám phá khi bạn đưa ra một lỗi trong mã của mình

Đôi khi chúng tôi làm việc trong các dự án trong một thời gian dài. Chúng tôi có thể tạo ra bản phát hành 1.0 hoàn hảo, sau đó chúng tôi phát hành nó ra công chúng và chúng tôi bắt đầu làm việc với các bản sửa lỗi, sau đó chúng tôi nhận được các yêu cầu về tính năng và chúng tôi làm việc để cải thiện ứng dụng.

Tại một số điểm trong quá trình này, bạn nhận được mộtlỗi hồi quy: sự cố không mong muốn do thay đổi mã không liên quan gây ra.

Có điều gì đó không hoạt động như mong đợi, mặc dù gần đây bạn không thực sự thay đổi phần mã đó.

Hoặc có thể bạn đã chạm vào tệp hoặc chức năng nhiều lần đến mức bạn không thể nhớ thay đổi nào có thể đã gây ra sự cố đã được báo cáo cho bạn.

Trong mọi trường hợp, điều đầu tiên cần làm làxác định lỗi ở đâu.

Nếu bạn làm việc bằng hệ thống kiểm soát lập phiên bản nhưGit, mọi thứ dễ dàng hơn. Bạn có thể quay ngược thời gian và tìm ra cam kết chính xác đã đưa ra thay đổi. Khi làm việc theo nhóm, điều này rất quan trọng vì một số người khác có thể đã làm việc đó và nếu họ gây ra lỗi, bạn có thể không biết phải làm gì - ngoại trừ việc yêu cầu họ sửa lỗi, vì Git cung cấp cho bạn thông tin này.

Một cách để làm điều này là kiểm tra thủ công một số cam kết cụ thể. Ví dụ: bạn có thể bắt đầu bằng cách kiểm tra xem phiên bản codebase ngày hôm qua có hoạt động tốt hay không.

tôi sử dụngGitHub Máy tính để bàn, ứng dụng Git tuyệt vời củaGitHub. Nó tuyệt vời để sử dụng hàng ngày, nhưng nó không cho phép tôi kiểm tra một cam kết nào. Một số khách hàng khác thì có, nhưng bạn có thể sử dụngdòng lệnh.

Chạy

git checkout <COMMIT_SHA>

Ở đâulà cam kết mà bạn muốn quay lại. Nó sẽ trông giống như5a06d3ca5e7adb6e67.

Nếu bạn vẫn gặp sự cố, hãy thử làm tương tự với một cam kết khác từ ngày hôm trước, v.v., cho đến khi bạn tìm thấy một cam kết mà mã hoạt động.

Bây giờ bạn cần áp dụngphân chia và chinh phụcnguyên tắc và chọn một cam kết ở giữa cái cuối cùng mà bạn đã thử (và không hiệu quả) và cái hoạt động.

Lặp lại quy trình và cắt đôi mỗi lần khoảng thời gian cam kết, cho đến khi bạn xác định được cam kết đã gây ra vấn đề.

Đây là một điều phổ biến và hữu ích mà Git đã giới thiệubisectlệnh để tự động hóa quá trình này.

Bắt đầu từ cam kết mới nhất của bạn. Sử dụnggit checkout your-branch-name, ví dụgit checkout masternếu bạn đã kiểm tra một cam kết cũ hơn.

Sau đó chạy:

git bisect start

Vẫn chưa có gì xảy ra. Bạn cần nói với Git mộtxấuTham chiếu cam kết, nơi mã không hoạt động:

git bisect bad HEAD

và mộttốtcam kết, nơi mã hoạt động:

git bisect good 7f4d976e7540e28c6b0

Git bắt đầu quá trình:

Bisecting: 3 revisions left to test after this (roughly 2 steps)
[d18ebf1c7db9a9b44e8facc5ddb3551e641a64e2] fixes #25

Thấy chưa, bạn có 6 cam kết giữa HEAD và cam kết mà tôi đã đề cập là tốt. Git cho tôi biết tôi còn 2 bước nữa cho đến khi chúng tôi tìm thấy cam kết có vấn đề.

Tôi đi và kiểm tra mã, sau đó tôi cho Git biết kết quả:git bisect badhoặc làgit bisect goodtùy thuộc vào sự thành công.

Lặp lại cho đến khi bạn tìm thấy cam kết không hợp lệ, sau đó chạygit bisect resetđể quay lại cam kết HEAD.

Git sẽ hướng dẫn bạn thao tác chia đôi này. Bạn nhập SHA của cam kết


Thêm hướng dẫn git: