Другая возможность состоит в том, что у вас есть ошибка, и вы знаете, что ее не было в февральском выпуске, но это было в апрельском выпуске (или, скорее, в апрельском выпуске кандидат - вы бы никогда не отправляйте сообщение об ошибке своим пользователям, верно?).
Вы можете выполнить бинарный поиск вручную по своей истории контроля версий, чтобы сузить время появления ошибки. Сначала проверьте код на полпути между двумя выпусками, соберите его и посмотрите, есть ли ошибка. Продолжайте разбиение, пока не узнаете, когда оно было введено. Если вы не знаете, с чего начать поиск ошибки, это может быть очень эффективным, особенно если вы делаете довольно небольшие коммиты.
Это очень хорошо работает с Subversion , потому что он имеет номера ревизий в репозитории. Если ваш февральский выпуск был 533-й версией, а ваш апрельский выпуск был 701-й версией, то вы обновляетесь до 617-й версии, тестируете его и идете оттуда. (На самом деле, я обычно округляю до 600, поэтому мне не нужно делать много математики в моей голове.) Как только я начинаю сужать это, я начинаю смотреть на комментарии коммита и делать обоснованные предположения («Я действительно не думаю, что этот коммит сломал бы его "), поэтому мне обычно не нужно делать все проверки журнала 2 (n).
Я никогда не использовал Git , но они продвинулись на один шаг дальше со встроенной командой " bisect ". Вы даете ему начальную точку (когда было известно, что она работает?) И конечную точку (когда вы заметили, что она сломана?), И она автоматически получит код для половины пути в бинарном поиске. Затем, после того как вы собрали и протестировали, вы сообщаете ему, прошел ли этот оборот или нет; затем он получает код для следующего промежуточного пункта. Вы можете даже сказать ему, чтобы он запускал команду для каждой версии и использовал код завершения команды, чтобы определить, является ли эта проверка успешной или неудачной, и в этот момент она может работать в полностью автоматическом режиме.