Регрессии — это большая проблема в индустрии программного обеспечения. Но трудно подкрепить это утверждение реальными цифрами.

Существуют некоторые цифры об ошибках в целом, например, исследование NIST в 2002 году [1], в котором говорилось:

И затем:

В конце концов, вывод начинался со слов:

Существуют и другие оценки, согласно которым 80% затрат, связанных с программным обеспечением, приходится на обслуживание [2].

Однако, согласно Википедии [3]:

Но можно предположить, что улучшение существующего программного обеспечения обходится очень дорого, потому что нужно следить за регрессиями. По крайней мере, это сделало бы вышеупомянутые исследования непротиворечивыми между собой.

Конечно, некоторые виды программного обеспечения разрабатываются, затем используются некоторое время без особых улучшений, а затем, наконец, отбрасываются. В этом случае, конечно, регрессии могут не быть большой проблемой. Но, с другой стороны, существует много большого программного обеспечения, которое постоянно разрабатывается и поддерживается в течение многих лет или даже десятков лет большим количеством людей. И поскольку часто много людей зависят (иногда критически) от такого программного обеспечения, регрессии представляют собой действительно большую проблему.

Одним из таких программных продуктов является ядро Linux. И если мы посмотрим на ядро Linux, то увидим, что на борьбу с регрессиями тратится много времени и усилий. Цикл выпуска начинается с двухнедельного окна слияния (merge window). Затем помечается первая версия-кандидат на выпуск (rc). И после этого появится ещё около 7 или 8 версий rc с интервалом около одной недели между ними, перед финальным выпуском.

Время между первым выпуском rc и финальным выпуском должно использоваться для тестирования версий rc и борьбы с ошибками и особенно регрессиями. И это время составляет более 80% времени цикла выпуска. Но на этом борьба не заканчивается, так как она, конечно, продолжается и после выпуска.

И вот что говорит Инг Молнар (хорошо известный разработчик ядра Linux) о своём использовании git bisect:

Таким образом, разработчики постоянно борются с регрессиями, и, действительно, хорошо известно, что ошибки следует исправлять как можно скорее, сразу после их обнаружения. Именно поэтому важно иметь хорошие инструменты для этой цели.

Итак, какие инструменты используются для борьбы с регрессиями? Они почти те же, что и для борьбы с обычными ошибками. Единственными специфическими инструментами являются наборы тестов и инструменты, подобные «git bisect».

Наборы тестов очень хороши. Но когда они используются сами по себе, предполагается, что все тесты будут проверяться после каждого коммита. Это означает, что они не очень эффективны, потому что многие тесты запускаются без получения интересного результата, и они страдают от комбинаторного взрыва.

На самом деле проблема в том, что большое программное обеспечение часто имеет множество различных параметров конфигурации, и каждый тестовый пример должен проходить для каждой конфигурации после каждого коммита. Таким образом, если для каждого выпуска у вас есть: N конфигураций, M коммитов и T тестовых примеров, вы должны выполнить:

где N, M и T — всё это растёт с размером вашего программного обеспечения.

Так что очень скоро станет невозможно полностью протестировать всё.

И если некоторые ошибки проскальзывают через ваш набор тестов, вы можете добавить тест в свой набор тестов. Но если вы хотите использовать свой новый улучшенный набор тестов, чтобы найти, где ошибка просочилась, то вам либо придётся эмулировать процесс двоичного поиска, либо, возможно, тупо тестировать каждый коммит в обратном порядке, начиная с имеющегося у вас «плохого» коммита, что может быть очень расточительно.

Первая подкоманда «git bisect», которую следует использовать — «git bisect start» для начала поиска. Затем должны быть установлены границы, чтобы ограничить пространство коммитов. Обычно это делается путём указания одного «плохого» и хотя бы одного «хорошего» коммита. Их можно передать в начальном вызове «git bisect start» следующим образом:

или они могут быть установлены с помощью:

и:

где ПЛОХОЙ, ХОРОШИЙ и КОММИТ — это имена, которые могут быть преобразованы в коммит.

Затем «git bisect» переключится на выбранный им коммит и попросит пользователя протестировать его, например:

Обратите внимание, что пример, который мы будем использовать, на самом деле является игрушечным примером. Мы будем искать первый коммит, который имеет версию типа «2.6.26-something», то есть коммит, который имеет строку «SUBLEVEL = 26» в корневом Makefile. Это игрушечный пример, потому что есть лучшие способы найти этот коммит с помощью Git, чем использовать «git bisect» (например, «git blame» или «git log -S<строка>»).

На этом этапе есть в основном 2 способа управления поиском. Он может управляться вручную пользователем или автоматически сценарием или командой.

Если пользователь управляет им вручную, то на каждом шаге поиска пользователь должен протестировать текущий коммит и сказать, является ли он «хорошим» или «плохим», используя соответственно команды «git bisect good» или «git bisect bad», описанные выше. Например:

И после ещё нескольких подобных шагов «git bisect» в конце концов найдёт первый плохой коммит:

На этом этапе мы можем увидеть, что делает коммит, переключиться на него (если он ещё не переключён) или возиться с ним, например:

И когда мы закончим, мы можем использовать «git bisect reset», чтобы вернуться в ветку, в которой мы были до начала двоичного поиска:

Другой способ управления процессом двоичного поиска — сказать «git bisect», чтобы он запускал сценарий или команду на каждом шаге, чтобы узнать, является ли текущий коммит «хорошим» или «плохим». Для этого мы используем команду «git bisect run». Например:

В этом примере мы передали «grep ^SUBLEVEL = 25 Makefile» в качестве параметра в «git bisect run». Это означает, что на каждом шаге будет запускаться переданная нами команда grep. И если она завершится с кодом 0 (что означает успех), то git bisect пометит текущее состояние как «хорошее». Если она завершится с кодом 1 (или любым кодом от 1 до 127 включительно, кроме специального кода 125), то текущее состояние будет помечено как «плохое».

Коды завершения от 128 до 255 являются специальными для «git bisect run». Они заставляют его немедленно остановить процесс двоичного поиска. Это полезно, например, если переданная команда выполняется слишком долго, потому что вы можете завершить её сигналом, и это остановит процесс двоичного поиска.

Это также может быть полезно в сценариях, передаваемых в «git bisect run», для «exit 255», если обнаружена какая-то очень ненормальная ситуация.

Иногда случается, что текущее состояние не может быть протестировано, например, если оно не компилируется из-за ошибки, существовавшей в то время. Для этого и предназначен специальный код завершения 125. Он сообщает «git bisect run», что текущий коммит должен быть помечен как не тестируемый и что должен быть выбран и переключён другой.

Если процесс двоичного поиска управляется вручную, вы можете использовать «git bisect skip», чтобы сделать то же самое. (На самом деле специальный код завершения 125 заставляет «git bisect run» использовать «git bisect skip» в фоновом режиме.)

Или если вы хотите больше контроля, вы можете проверить текущее состояние, используя, например, «git bisect visualize». Он запустит gitk (или «git log», если переменная окружения DISPLAY не установлена), чтобы помочь вам найти лучшую точку для двоичного поиска.

В любом случае, если у вас есть цепочка не тестируемых коммитов, может случиться так, что регрессия, которую вы ищете, была внесена одним из этих не тестируемых коммитов. В этом случае невозможно точно сказать, какой коммит внёс регрессию.

Поэтому, если вы использовали «git bisect skip» (или сценарий запуска завершился со специальным кодом 125), вы можете получить результат, подобный этому:

Если вы хотите показать другим людям свой процесс двоичного поиска, вы можете получить журнал, используя, например:

И его можно воспроизвести, используя:

Поскольку коммиты Git образуют направленный ациклический граф (DAG), поиск наилучшего коммита для тестирования на каждом шаге не так прост. Тем не менее Линус нашёл и реализовал «по-настоящему тупой» алгоритм, позже улучшенный Джунио Хамано, который работает довольно хорошо.

Итак, алгоритм, используемый «git bisect» для поиска наилучшего коммита для двоичного поиска, когда нет пропущенных коммитов, выглядит следующим образом:

1) оставить только те коммиты, которые:

a) являются предками «плохого» коммита (включая сам «плохой» коммит), b) не являются предками «хорошего» коммита (исключая сами «хорошие» коммиты).

Это означает, что мы избавляемся от неинтересных коммитов в DAG.

Например, если мы начнём с графа, подобного этому:

где B — это «плохой» коммит, «G» — «хорошие» коммиты, а W, X и Y — другие коммиты, мы получим следующий граф после этого первого шага:

Таким образом, будут сохранены только коммиты W и B. Поскольку коммиты X и Y будут удалены правилами a) и b) соответственно, и потому что коммиты G также удаляются правилом b).

Примечание для пользователей Git: это эквивалентно сохранению только коммита, заданного:

Также обратите внимание, что мы не требуем, чтобы сохраняемые коммиты были потомками «хорошего» коммита. Таким образом, в следующем примере будут сохранены коммиты W и Z:

2) начиная с «хороших» концов графа, сопоставить каждому коммиту количество его предков плюс один

Например, для следующего графа, где H — это «плохой» коммит, а A и D — некоторые родители некоторых «хороших» коммитов:

это даст:

3) сопоставить каждому коммиту: min(X, N - X)

где X — это значение, связанное с коммитом на шаге 2), а N — общее количество коммитов в графе.

В приведённом выше примере N = 8, так что это даст:

4) наилучшая точка для двоичного поиска — это коммит с наибольшим связанным числом

Таким образом, в приведённом выше примере наилучшая точка для двоичного поиска — это коммит C.

5) обратите внимание, что некоторые сокращения реализованы для ускорения алгоритма

Поскольку мы знаем N с самого начала, мы знаем, что min(X, N - X) не может быть больше N/2. Поэтому во время шагов 2) и 3), если мы сопоставим N/2 коммиту, то мы знаем, что это наилучшая точка для двоичного поиска. Таким образом, в этом случае мы можем просто прекратить обработку любых других коммитов и вернуть текущий коммит.

Для любого графа коммитов вы можете увидеть число, связанное с каждым коммитом, используя «git rev-list --bisect-all».

Например, для приведённого выше графа команда, подобная:

выдаст что-то вроде:

Сначала давайте определим «наилучшую точку для двоичного поиска». Мы будем говорить, что коммит X является наилучшей точкой для двоичного поиска или наилучшим коммитом для двоичного поиска, если знание его состояния («хорошее» или «плохое») даёт как можно больше информации о том, является ли состояние коммита «хорошим» или «плохим».

Это означает, что наилучшие коммиты для двоичного поиска — это коммиты, где следующая функция максимальна:

где информация_если_хороший(X) — это информация, которую мы получаем, если X хороший, а информация_если_плохой(X) — это информация, которую мы получаем, если X плохой.

Теперь мы предположим, что существует только один «первый плохой коммит». Это означает, что все его потомки «плохие», а все остальные коммиты «хорошие». И мы предположим, что все коммиты имеют равную вероятность быть хорошими или плохими, или быть первым плохим коммитом, поэтому знание состояния c коммитов всегда даёт одинаковое количество информации, независимо от того, где эти c коммитов находятся на графе и независимо от c. (Таким образом, мы предполагаем, что тот факт, что эти коммиты находятся, например, на ветке или рядом с хорошим или плохим коммитом, не даёт больше или меньше информации).

Предположим также, что у нас есть очищенный граф, как после шага 1) в алгоритме двоичного поиска выше. Это означает, что мы можем измерить получаемую информацию в терминах количества коммитов, которые мы можем удалить из графа.

И давайте возьмём коммит X в графе.

Если X оказывается «хорошим», то мы знаем, что все его предки «хорошие», поэтому мы хотим сказать, что:

И это верно, потому что на шаге 1) b) мы удаляем предков «хороших» коммитов.

Если X оказывается «плохим», то мы знаем, что все его потомки «плохие», поэтому мы хотим сказать, что:

Но это неверно, потому что на шаге 1) a) мы сохраняем только предков плохого коммита. Таким образом, мы получаем больше информации, когда коммит помечается как «плохой», потому что мы также знаем, что предки предыдущего «плохого» коммита, которые не являются предками нового «плохого» коммита, не являются первым плохим коммитом. Мы не знаем, хорошие они или плохие, но мы знаем, что они не являются первым плохим коммитом, потому что они не являются предками нового «плохого» коммита.

Поэтому, когда коммит помечается как «плохой», мы знаем, что можем удалить все коммиты в графе, кроме тех, которые являются предками нового «плохого» коммита. Это означает, что:

где N — количество коммитов в (очищенном) графе.

Итак, в итоге это означает, что для поиска наилучших коммитов для двоичного поиска мы должны максимизировать функцию:

И это хорошо, потому что на шаге 2) мы вычисляем количество_предков(X), и, следовательно, на шаге 3) мы вычисляем f(X).

Давайте возьмём следующий граф в качестве примера:

Если мы вычислим на нём следующую неоптимальную функцию:

мы получаем:

но с алгоритмом, используемым git bisect, мы получаем:

Таким образом, мы выбираем G, H, K или L в качестве наилучшей точки для двоичного поиска, что лучше, чем F. Потому что если, например, L плохой, то мы будем знать не только то, что L, M и N плохие, но и то, что G, H, I и J не являются первым плохим коммитом (поскольку мы предполагаем, что существует только один первый плохой коммит, и он должен быть предком L).

Таким образом, текущий алгоритм, кажется, является наилучшим из возможных, учитывая то, что мы изначально предположили.

Когда некоторые коммиты были пропущены (с помощью «git bisect skip»), то алгоритм двоичного поиска для шагов 1) - 3) остаётся тем же. Но затем мы используем примерно следующие шаги:

6) отсортировать коммиты по убыванию связанного значения

7) если первый коммит не был пропущен, мы можем вернуть его и остановиться здесь

8) в противном случае отфильтровать все пропущенные коммиты в отсортированном списке

9) использовать генератор псевдослучайных чисел (PRNG) для генерации случайного числа от 0 до 1

10) умножить это случайное число на его квадратный корень для смещения к 0

11) умножить результат на количество коммитов в отфильтрованном списке, чтобы получить индекс в этом списке

12) вернуть коммит по вычисленному индексу

После шага 7) (в алгоритме пропуска) мы могли бы проверить, был ли пропущен второй коммит, и вернуть его, если это не так. И на самом деле это был алгоритм, который мы использовали с момента разработки «git bisect skip» в Git версии 1.5.4 (выпущена 1 февраля 2008 г.) до Git версии 1.6.4 (выпущена 29 июля 2009 г.).

Но Инг Молнар и Х. Питер Анвин (ещё один известный разработчик ядра Linux) оба жаловались, что иногда наилучшие точки для двоичного поиска все оказывались в области, где все коммиты не тестируемы. И в этом случае пользователя просили протестировать много не тестируемых коммитов, что могло быть очень неэффективно.

Действительно, не тестируемые коммиты часто не тестируемы, потому что в какой-то момент была внесена поломка, и эта поломка была исправлена только после того, как было внесено много других коммитов.

Эта поломка, конечно, в большинстве случаев не связана с поломкой, которую мы пытаемся найти в графе коммитов. Но она мешает нам узнать, присутствует ли интересующее нас «плохое поведение» или нет.

Таким образом, факт состоит в том, что коммиты рядом с не тестируемым коммитом имеют высокую вероятность быть самими не тестируемыми. И наилучшие коммиты для двоичного поиска также часто встречаются вместе (из-за алгоритма двоичного поиска).

Вот почему выбирать следующий наилучший непропущенный коммит для двоичного поиска, когда первый был пропущен, — это плохая идея.

Мы обнаружили, что большинство коммитов на графе могут дать довольно много информации, когда они протестированы. А коммиты, которые в среднем не дают много информации, — это те, которые находятся рядом с хорошими и плохими коммитами.

Таким образом, использование PRNG со смещением в пользу коммитов, далёких от хороших и плохих коммитов, выглядело хорошим выбором.

Одним из очевидных улучшений этого алгоритма было бы поиск коммита, который имеет связанное значение, близкое к значению наилучшего коммита для двоичного поиска, и который находится в другой ветке, перед использованием PRNG. Потому что если такой коммит существует, то он вряд ли также будет не тестируемым, поэтому он, вероятно, даст больше информации, чем почти случайно выбранный.

Существует ещё одна настройка в алгоритме двоичного поиска, которая не была описана в разделе «Алгоритм двоичного поиска» выше.

В предыдущих примерах мы предполагали, что «хорошие» коммиты являются предками «плохого» коммита. Но это не является требованием «git bisect».

Конечно, «плохой» коммит не может быть предком «хорошего» коммита, потому что предки хороших коммитов должны быть «хорошими». И все «хорошие» коммиты должны быть связаны с плохим коммитом. Они не могут находиться в ветке, не имеющей связи с веткой «плохого» коммита. Но возможно, что хороший коммит связан с плохим коммитом, но при этом не является ни его предком, ни его потомком.

Например, может быть ветка «main» и ветка «dev», которая была ответвлена от ветки main в коммите с именем «D», как показано:

Коммит «D» называется «базой слияния» для веток «main» и «dev», потому что это наилучший общий предок для этих веток для слияния.

Теперь предположим, что коммит J плохой, а коммит G хороший, и мы применяем алгоритм двоичного поиска, как он был описан ранее.

Как описано на шаге 1) b) алгоритма двоичного поиска, мы удаляем всех предков хороших коммитов, потому что они также должны быть хорошими.

Таким образом, у нас останется только:

Но что произойдёт, если первый плохой коммит — это «B», и он был исправлен в ветке «main» коммитом «F»?

Результатом такого двоичного поиска будет то, что мы найдём, что H — это первый плохой коммит, когда на самом деле это B. Так что это было бы неправильно!

И да, на практике может случиться так, что люди, работающие в одной ветке, не знают, что люди, работающие в другой ветке, исправили ошибку! Также могло случиться, что F исправил более одной ошибки или что это был откат какого-то большого объёма разработки, который не был готов к выпуску.

На самом деле команды разработчиков часто поддерживают как ветку разработки, так и ветку сопровождения, и для них было бы довольно удобно, если бы «git bisect» просто работал, когда они хотят выполнить двоичный поиск регрессии в ветке разработки, которой нет в ветке сопровождения. Они должны иметь возможность начать двоичный поиск, используя:

Чтобы включить эту дополнительную полезную функцию, когда начинается двоичный поиск и когда некоторые хорошие коммиты не являются предками плохого коммита, мы сначала вычисляем базы слияния между плохим и хорошими коммитами и выбираем эти базы слияния в качестве первых коммитов, которые будут переключены и протестированы.

Если окажется, что одна из баз слияния является плохой, то процесс двоичного поиска останавливается с сообщением, подобным:

где BBBBBB — это sha1-хеш плохой базы слияния, а [GGGGGG,…​] — это разделённый запятыми список sha1-хешей хороших коммитов.

Если некоторые из баз слияния пропущены, то процесс двоичного поиска продолжается, но для каждой пропущенной базы слияния выводится следующее сообщение:

где BBBBBB — это sha1-хеш плохого коммита, MMMMMM — это sha1-хеш пропущенной базы слияния, а [GGGGGG,…​] — это разделённый запятыми список sha1-хешей хороших коммитов.

Таким образом, если нет плохой базы слияния, процесс двоичного поиска продолжается как обычно после этого шага.

Если у вас есть набор тестов и вы используете git bisect, то проверка того, что все тесты проходят после каждого коммита, становится менее важной. Хотя, конечно, вероятно, это хорошая идея — иметь некоторые проверки, чтобы избежать поломки слишком большого количества вещей, так как это может сделать двоичный поиск других ошибок более сложным.

Вы можете сосредоточить свои усилия на проверке в нескольких точках (например, релизы rc и бета-версии), чтобы все T тестовых случаев проходили для всех N конфигураций. И когда некоторые тесты не проходят, вы можете использовать «git bisect» (или лучше «git bisect run»). Таким образом, вы должны выполнить примерно:

где c — количество раундов тестирования (то есть небольшая константа), а b — доля ошибок на коммит (надеюсь, тоже небольшая константа).

Таким образом, конечно, это намного лучше, так как это O(N * T) против O(N * T * M), если бы вы тестировали всё после каждого коммита.

Это означает, что наборы тестов хороши для предотвращения попадания некоторых ошибок в коммиты, и они также довольно хороши для того, чтобы сообщить вам, что у вас есть некоторые ошибки. Но они не очень хороши для того, чтобы сказать вам, где были внесены некоторые ошибки. Чтобы эффективно сообщить вам это, необходим git bisect.

Ещё одна приятная особенность наборов тестов заключается в том, что когда он у вас есть, вы уже знаете, как тестировать на наличие плохого поведения. Таким образом, вы можете использовать эти знания для создания нового тестового примера для «git bisect», когда обнаруживается регрессия. Так будет легче выполнить двоичный поиск ошибки и исправить её. А затем вы можете добавить только что созданный тестовый пример в свой набор тестов.

Таким образом, если вы знаете, как создавать тестовые примеры и как выполнять двоичный поиск, вы попадёте в благотворный круг:

больше тестов ⇒ легче создавать тесты ⇒ легче выполнять двоичный поиск ⇒ больше тестов

Таким образом, наборы тестов и «git bisect» являются взаимодополняющими инструментами, которые очень мощны и эффективны при совместном использовании.

Вы можете очень легко автоматически выполнять двоичный поиск сломанных сборок, используя что-то вроде:

Например:

С другой стороны, если вы делаете это часто, то может быть полезно иметь сценарии, чтобы избежать слишком большого количества набора текста.

Вот пример сценария, немного изменённого по сравнению с реальным сценарием, используемым Джунио Хамано [4].

Этот сценарий можно передать в «git bisect run», чтобы найти коммит, который внёс регрессию производительности:

Очевидно, что хорошей идеей является не иметь коммитов с изменениями, которые заведомо ломают что-то, даже если позже некоторые другие коммиты исправляют поломку.

Также хорошей идеей при использовании любой VCS является наличие только одного небольшого логического изменения в каждом коммите.

Чем меньше изменения в вашем коммите, тем эффективнее будет «git bisect». И, вероятно, вам меньше понадобится «git bisect», поскольку небольшие изменения легче проверять, даже если они проверяются только коммиттером.

Ещё одна хорошая идея — иметь хорошие сообщения коммитов. Они могут быть очень полезны для понимания того, почему были сделаны некоторые изменения.

Эти общие лучшие практики очень полезны, если вы часто выполняете двоичный поиск.

Во-первых, сами по себе слияния могут вносить некоторые регрессии, даже когда слияние не требует разрешения конфликтов в исходном коде. Это происходит потому, что семантическое изменение может произойти в одной ветке, в то время как другая ветка не знает о нём.

Например, одна ветка может изменить семантику функции, а другая ветка добавляет больше вызовов той же функции.

Это становится намного хуже, если для разрешения конфликтов приходится исправлять много файлов. Вот почему такие слияния называются «злыми слияниями» (evil merges). Они могут сделать регрессии очень трудными для отслеживания. Это даже может ввести в заблуждение при определении первого плохого коммита, если им окажется такое слияние, потому что люди могут подумать, что ошибка происходит из-за плохого разрешения конфликта, когда она исходит из семантического изменения в одной ветке.

В любом случае «git rebase» может использоваться для линеаризации истории. Это можно использовать либо для того, чтобы вообще избежать слияния, либо для того, чтобы выполнять двоичный поиск на линейной истории вместо нелинейной, поскольку это должно дать больше информации в случае семантического изменения в одной ветке.

Слияния также можно сделать проще, используя более мелкие ветки или используя множество тематических веток вместо только длинных веток, связанных с версиями.

И тестирование можно проводить чаще в специальных интеграционных ветках, таких как linux-next для ядра Linux.

Специальный рабочий процесс для обработки регрессий может дать отличные результаты.

Вот пример рабочего процесса, используемого Андреасом Эрикссоном:

И вот что Андреас сказал об этом рабочем процессе [5]:

Очевидно, что этот рабочий процесс использует благотворный круг между наборами тестов и «git bisect». На самом деле он делает это стандартной процедурой для работы с регрессиями.

В других сообщениях Андреас говорит, что они также используют «лучшие практики», описанные выше: небольшие логические коммиты, тематические ветки, отсутствие злых слияний,…​ Эти практики улучшают возможность двоичного поиска в графе коммитов, делая двоичный поиск проще и полезнее.

Таким образом, хороший рабочий процесс должен быть разработан с учётом вышеуказанных моментов. То есть делать двоичный поиск проще, полезнее и стандартным.

Одна из приятных особенностей «git bisect» заключается в том, что это не только инструмент разработчика. Он может эффективно использоваться специалистами по обеспечению качества или даже конечными пользователями (если у них есть доступ к исходному коду или если они могут получить доступ ко всем сборкам).

В какой-то момент в списке рассылки ядра Linux велось обсуждение о том, нормально ли всегда просить конечного пользователя выполнять двоичный поиск, и были приведены очень хорошие аргументы в поддержку точки зрения, что это нормально.

Например, Дэвид Миллер написал [6]:

Это означает, что часто это «дешевле», если это могут сделать специалисты по обеспечению качества или конечные пользователи.

Что также интересно, так это то, что конечные пользователи, сообщающие об ошибках (или специалисты по обеспечению качества, воспроизвёдшие ошибку), имеют доступ к среде, в которой возникает ошибка. Поэтому они часто могут легче воспроизвести регрессию. И если они могут выполнить двоичный поиск, то из среды, в которой возникает ошибка, будет извлечено больше информации, что означает, что будет легче понять, а затем и исправить ошибку.

Для проектов с открытым исходным кодом это может быть хорошим способом получить более полезный вклад от конечных пользователей и познакомить их с деятельностью по обеспечению качества и разработкой.

В некоторых случаях, например, при разработке ядра, может быть полезно разработать сложные сценарии, чтобы полностью автоматизировать двоичный поиск.

Вот что Инг Молнар говорит об этом [7]:

Мы видели, что наборы тестов и git bisect очень мощны при совместном использовании. Это может быть ещё более мощно, если вы можете комбинировать их с другими системами.

Например, некоторые наборы тестов могут запускаться автоматически ночью с некоторыми необычными (или даже случайными) конфигурациями. И если набор тестов обнаружит регрессию, то «git bisect» может быть запущен автоматически, а его результат может быть отправлен по электронной почте автору первого плохого коммита, найденного «git bisect», и, возможно, другим людям. Также может быть автоматически создана новая запись в системе отслеживания ошибок.

Ранее мы видели, что «git bisect skip» теперь использует PRNG, чтобы попытаться избежать областей в графе коммитов, где коммиты не тестируемы. Проблема в том, что иногда первый плохой коммит может находиться в не тестируемой области.

Чтобы упростить обсуждение, мы предположим, что не тестируемая область представляет собой простую цепочку коммитов, и она была создана поломкой, внесённой одним коммитом (назовём его BBC — bisect breaking commit), а позже исправленной другим (назовём его BFC — bisect fixing commit).

Например:

где мы знаем, что Y хороший, а BFC плохой, и где BBC и X1-X6 не тестируемы.

В этом случае, если вы выполняете двоичный поиск вручную, вы можете создать специальную ветку, которая начинается непосредственно перед BBC. Первым коммитом в этой ветке должен быть BBC с вжатым в него BFC. А остальные коммиты в ветке должны быть коммитами между BBC и BFC, перемещёнными на первый коммит ветки, а затем коммит после BFC также перемещённым.

Например:

где коммиты, отмеченные символом ', были перемещены.

Вы можете легко создать такую ветку в Git, используя интерактивное перемещение.

Например, используя:

а затем переместить BFC после BBC и вжать его.

После этого вы можете начать двоичный поиск как обычно в новой ветке, и вы должны в конце концов найти первый плохой коммит.

Например:

Если вы используете «git bisect run», вы можете использовать то же ручное исправление, что и выше, а затем запустить другой «git bisect run» в специальной ветке. Или, как говорится в справочной странице «git bisect», сценарий, передаваемый в «git bisect run», может применить патч перед компиляцией и тестированием программного обеспечения [8]. Патч должен превратить текущий не тестируемый коммит в тестируемый. Таким образом, тестирование даст результат «хороший» или «плохой», и «git bisect» сможет найти первый плохой коммит. И сценарий не должен забыть удалить патч после завершения тестирования перед выходом из сценария.

(Обратите внимание, что вместо патча вы можете использовать «git cherry-pick BFC», чтобы применить исправление, и в этом случае вы должны использовать «git reset --hard HEAD^», чтобы отменить cherry-pick после тестирования и перед возвратом из сценария.)

Но описанные выше способы обхода не тестируемых областей немного громоздки. Использование специальных веток удобно, потому что эти ветки могут совместно использоваться разработчиками как обычные ветки, но риск в том, что у людей будет много таких веток. И это нарушает нормальный рабочий процесс «git bisect». Таким образом, если вы хотите использовать «git bisect run» полностью автоматически, вам нужно добавить специальный код в свой сценарий, чтобы перезапускать двоичный поиск в специальных ветках.

В любом случае, можно заметить в приведённом выше примере специальной ветки, что коммиты Z' и Z должны указывать на одно и то же состояние исходного кода (то же самое «дерево» в терминологии git). Это потому, что Z' получается в результате применения тех же изменений, что и Z, просто в несколько ином порядке.

Таким образом, если бы мы могли просто «заменить» Z на Z' при двоичном поиске, то нам не нужно было бы ничего добавлять в сценарий. Это просто работало бы для любого в проекте, кто разделяет специальные ветки и замены.

С приведённым выше примером это дало бы:

Вот почему была создана команда «git replace». Технически она хранит ссылки замены в иерархии «refs/replace/». Эти «ссылки» похожи на ветки (которые хранятся в «refs/heads/») или метки (которые хранятся в «refs/tags»), и это означает, что они могут автоматически совместно использоваться как ветки или метки между разработчиками.

«git replace» — очень мощный механизм. Он может использоваться для исправления коммитов в уже выпущенной истории, например, для изменения сообщения коммита или автора. И он также может использоваться вместо git «grafts» для связывания репозитория с другим старым репозиторием.

На самом деле именно эта последняя функция «продала» его сообществу Git, так что теперь она находится в ветке «master» Git-репозитория Git и должна быть выпущена в Git 1.6.5 в октябре или ноябре 2009 года.

Одна проблема с «git replace» заключается в том, что в настоящее время он хранит все ссылки замены в «refs/replace/», но, возможно, было бы лучше, если бы ссылки замены, которые полезны только для двоичного поиска, находились бы в «refs/replace/bisect/». Таким образом, ссылки замены могли бы использоваться только для двоичного поиска, в то время как другие ссылки непосредственно в «refs/replace/» использовались бы практически постоянно.

Другим возможным улучшением «git bisect» было бы добавление некоторой избыточности в выполняемые тесты, чтобы он был более надёжным при отслеживании спорадических ошибок.

Это было запрошено некоторыми разработчиками ядра, потому что некоторые ошибки, называемые спорадическими, появляются не во всех сборках ядра, так как они очень зависят от вывода компилятора.

Идея в том, что, например, каждые 3 теста «git bisect» может попросить пользователя протестировать коммит, который уже был признан «хорошим» или «плохим» (потому что один из его потомков или один из его предков был признан соответственно «хорошим» или «плохим»). Если окажется, что коммит был ранее неправильно классифицирован, то двоичный поиск может быть прерван на ранней стадии, надеюсь, до того, как будет сделано слишком много ошибок. Затем пользователь должен будет посмотреть, что произошло, и затем перезапустить двоичный поиск, используя исправленный журнал двоичного поиска.

Уже существует проект под названием BBChop, созданный Ealdwulf Wuffinga на Github, который делает нечто подобное, используя теорию байесовского поиска [9]:

Но BBChop не зависит от какой-либо VCS, и для пользователей Git было бы проще иметь что-то интегрированное в Git.