Làm thế nào tôi có thể sử dụng git bisect để tìm cam kết TỐT đầu tiên?

Tôi có vấn đề sau:

• phiên bản masterhoạt động tốt
• phiên bản của thẻ cuối cùng trước master(giả sử last) có lỗi
• một đồng nghiệp cần một bản vá để lastsửa đổi cho một lỗi nhất định

Được chứ. Hãy hỏi bạn bè của chúng tôi git bisectvề bản sửa đổi đã sửa lỗi:

git bisect start
git bisect bad last
git bisect good master

Nhưng điều đó sẽ không hiệu quả:

Một số vòng quay tốt không phải là tổ tiên của vòng quay xấu.
git bisect không thể hoạt động bình thường trong trường hợp này.
Có thể bạn nhầm lẫn vòng quay tốt và xấu?

Bất kỳ gợi ý để vượt qua điều này? Tôi đã bỏ lỡ điều gì đó trong tài liệu?

Kể từ git 2.7, bạn có thể sử dụng các đối số --term-old và --term-new.

Ví dụ: bạn có thể xác định một cam kết khắc phục sự cố do đó:

git bisect start --term-new=fixed --term-old=unfixed
git bisect fixed master
git bisect unfixed $some-old-sha1

Khi bạn kiểm tra, hãy nói git bisect fixedhoặc git bisect unfixedkhi thích hợp.

Câu trả lời cũ, dành cho các phiên bản git trước 2.7

Thay vì tạm thời đào tạo bản thân để nghĩ rằng xấu có nghĩa là tốt và tốt có nghĩa là xấu, tại sao không tạo một số bí danh?

Trong ~/.gitconfigthêm những điều sau đây:

[alias]
        bisect-fixed = bisect bad
        bisect-unfixed = bisect good

Bạn có thể bắt đầu xác định một cam kết khắc phục sự cố do đó:

$ git bisect start
$ git bisect-fixed master
$ git bisect-unfixed $some-old-sha1

Khi bạn kiểm tra, hãy nói git bisect-fixedhoặc git bisect-unfixedkhi thích hợp.

Tôi sẽ chỉ "ăn gian" git và hoán đổi ý nghĩa của tốt <=> xấu.

Nói cách khác, hãy coi "xấu" là thứ không thể hiện vấn đề, vì vậy đây không phải là phiên bản "tốt" để bạn làm căn cứ cho bản vá.

Tốt và xấu dù sao cũng là những khái niệm khá chủ quan, phải không? :)

git bisect start
git bisect good last
git bisect bad master

Nếu bạn đang sử dụng git bisect runnhư tôi đã làm với provelệnh của Perl (chạy các bài kiểm tra tự động), bạn không có cơ hội chỉ để hoán đổi goodvà bad. Sự thành công của các thử nghiệm sẽ được báo cáo dưới dạng mã thoát.

Tôi đã tìm thấy một cú pháp Bash hợp lệ để phủ định mã thoát của chương trình do git bisect run:

git bisect start
git bisect bad HEAD                 # last revision known to PASS the tests
git bisect good $LAST_FAIL_REVISION # last revision known to FAIL the tests
git bisect run bash -c "! prove"

Điều này đã cho tôi bản sửa đổi đầu tiên để vượt qua các bài kiểm tra prove.

Git bây giờ cho phép bạn sử dụng oldvà newkhông đầu tiên định nghĩa chúng. Bạn phải gọi git bisect startmà không có cam kết như các đối số khác, sau đó bắt đầu phân chia đúng cách bằng cách gọi

git bisect old <rev>
git bisect new <rev>

https://git-scm.com/docs/git-bisect#_alternate_terms

Về cơ bản, đây là những gì @MarcH đã đề xuất nên được thực hiện.

Bí danh Git là một ý tưởng hay, tuy nhiên các điều khoản fixedvà unfixedcó cùng một vấn đề hơn là goodvà bad: bạn không thể có chúng tương thích với cả hồi quy và tiến trình. Thật dễ dàng để tìm thấy các từ hoạt động theo một trong hai cách: chỉ cần chọn chúng từ thuật ngữ tìm kiếm nhị phân ban đầu có bản chất trung lập không có định kiến ​​về điều gì là tốt hay xấu. Ví dụ:

git config --global alias.bisect-high 'bisect bad'
git config --global alias.bisect-low  'bisect good'

Với các thuật ngữ trung lập như thế này, bạn luôn có thể nhập: git bisect-high(hoặc git bisect-upper, hoặc git-bisect max, ... sự lựa chọn của bạn!) Cho dù bạn đang tìm kiếm hồi quy hay sửa chữa .

Thật tệ là các nhà phát triển git bisect không thể đơn giản sử dụng lại bất kỳ thuật ngữ nào hiện có. Nói chung, giao diện người dùng không phải là mối quan tâm của git: http://stevebennett.me/2012/02/24/10-things-i-hate-about-git/