>_ IzzyLab

Практическое задание

Найди сломавший коммит через bisect run

сложно

В репозитории /root/repo ветка main содержит длинную линейную историю коммитов с одинаковыми на вид сообщениями (step N). В какой-то момент в файл app.sh попала регрессия — в нём появилась строка со словом BROKEN. В самом первом коммите её ещё нет, в HEAD — уже есть. Найди первый коммит, где app.sh сломался, и запиши его полный хеш в файл /root/bad.txt. Перебирать коммиты руками долго — пусть git сам делит историю пополам, прогоняя на каждом шаге автоматическую проверку.

Что потренируешь:
  • git bisect
  • двоичный поиск
  • rev-list
  • автоматизация проверки
  • поиск регрессии

Разбор темы

Когда регрессия закралась где-то в длинной линейной истории, перебирать коммиты подряд — это O(n); двоичный поиск делает это за O(log n). git bisect берёт заведомо плохую и заведомо хорошую ревизии (самый первый коммит удобно достать через git rev-list --max-parents=0) и делит диапазон пополам, спрашивая на каждом шаге вердикт. Проверку можно автоматизировать скриптом, который завершается кодом 0 на «хорошем» состоянии и ненулевым на «плохом»; по окончании HEAD стоит на первом плохом коммите, а рабочее дерево возвращают через reset.

Что проверяется

  1. хеш записан
  2. это первый плохой коммит

Как это выглядит