Привет хабр!
Сегодня небольшой пост об очень удобной и полезной фиче гита — бинарный поиск, но сначала небольшое лирическое отступление :)

Сегодня в обед, придя на работу, наш ПМ говорит о том, что на сайте после нашего ночного апдейта появился блокер. Заключался он в следующем: у пользователей IE 11 крешился браузер при заходе на некоторые страницы сайта. Только в IE! Никаких ошибок в консоли, ничего, что могло бы указать направление, в котором стоило бы начать поиски и устранение дефекта. Счастливчиком, которому довелось исследовать сей баг оказался я.
Ну что ж, для простоты дебага я выбрал страницу на сайте, на которой меньше всего функционала и js скриптов. Изначально, я подумал, что браузер падает из-за какого-то js скрипта. И постепенно начал отключать скрипты один за одним, затем подключать обратно, дабы найти этот коварный код. И я оказался прав! Спустя 15 минут исследований, я нашел скрипт, при подключении которого все рушилось. Однако, на мое удивление, этим скриптом оказалась библиотека на 10 строчек кода, на которую я и подумать не мог. В прошлых релизах мы внедрили Lazy Loading изображений на сайте. Но тогда все работало, почему сломалось сейчас нужно было выяснить. Ковыряния 10-ти строк кода библиотеки ни к чему не приводили, попытки вывести хоть какую-то инфу в консоль браузера или обвернуть код в try {...} catch () {...} успехом так же не увенчались. Оставался только один вариант, искать коммит, на котором все поломалось. Но в текущем релизе было более 50 коммитов, я скорее поседел бы, чем смог их все просмотреть. И тут мне на помощь пришел бинарный поиск GIT'a. Что это такое?

Бинарный поиск — поиск по истории коммитов, который позволяет быстрее выявить коммит, на котором все сломалось. Как с ним работать? Предположим, у нас есть ветка dev, в которой нужный функционал сломан.
Переходим в папку с нашим репозиторем GIT
Пишем в терминале

$ git bisect start

Затем

$ git bisect bad

Команда говорит о том, что в текущем состоянии все сломано. Далее, нужно указать коммит, в котором все работало: git bisect good [ревизия_коммита], например:

$ git bisect good c5a2de0b2f01d8d159573ef682163d958c2ce4c2

На что гит ответит чем-то похожим:

Bisecting: 9 revisions left to test after this (roughly 3 steps)
[76a347ffc0a53610f9927cba24e7878c5148a3bd] mob version fix

Это означает, что между коммитом который вы указали и текущей версией примерно 18 коммитов и он переключился на версию из середины. Теперь вы можете прогнать необходимые тесты и проверить заработал ли функционал. Если функционал работает, то проблема появилась где-то позже, а если нет, соответственно — раньше.
Предположим, что в этом коммите функционал уже сломался, пишем:

$ git bisect bad
Bisecting: 5 revisions left to test after this (roughly 2 steps)
[631e66c26223a806df80038bd0f96d53685df8e5] Fix js

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

$ git bisect good
Bisecting: 1 revision left to test after this (roughly 1 step)
[fe0f7a960019c2d34353d7b8e9ddbcd6d0766074] added migration

И так далее, до тех пор, пока мы не найдем первый плохой коммит

$ git bisect good
fe0f7a960019c2d34353d7b8e9ddbcd6d0766074 is the first bad commit
commit fe0f7a960019c2d34353d7b8e9ddbcd6d0766074
Author: user <user@example.com>
Date:   Thu Mar 31 13:28:10 2016 +0300
views refactoring
:040000 040000 31e09fd7429b7c5d01708e02b204fc1ed7795fd6 73ef48a90f4ae194060e188a7ad6b899d301e95a M	dev

Чтобы выйти из режима поиска пишем:

$ git bisect reset

В итоге я просмотрел все изменения, который были сделаны в этом комите и заметил, что плейсхолдеры изображений были заменены с формата png на svg. Откатил изменения, проверили — все работает. Суть проблемы осталась не понятной, IE странно себя ведет с svg изображениями, но это уже следующий этап разбирательств. Мы выкатили обновление, чтобы пользователи IE могли пользоваться нашим сайтом. На все про все, у меня ушло пару минут. Без бинарного поиска, я бы потратил гораздо больше времени.

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