После релиза обнаружился баг, который появился где-то в последних 50 коммитах, но непонятно в каком именно. Как использовать git bisect для поиска проблемного коммита? Когда уместно применять git cherry-pick?

Короткий ответ

git bisect автоматизирует бинарный поиск: вы помечаете известный «хороший» и «плохой» коммит, а Git последовательно предлагает промежуточные коммиты для тестирования, сужая диапазон за логарифмическое число шагов; git cherry-pick уместен, когда нужно перенести один конкретный коммит (например, hotfix) в другую ветку без слияния всей истории.

Как это работает подробнее

git bisect start, затем bad/good на границах диапазона; Git чекаутит средний коммит, вы отмечаете результат — за ~log2(50)≈6 итераций находится первый плохой коммит. git bisect run <script> автоматизирует это при наличии автоматического теста.

Пример кода

Команды терминалаКопировать

git bisect start
git bisect bad HEAD
git bisect good v1.4.0
git bisect run pytest tests/test_regression.py::test_order_total
git bisect reset
git checkout release/1.5
git cherry-pick a1b2c3d

Что использовать на практике

• Рекомендация. перед bisect нужен надёжный тест, однозначно отличающий «баг есть» от «бага нет»; cherry-pick удобен для hotfix в несколько веток, но при частом использовании на много коммитов лучше рассмотреть merge/rebase.

Подводные камни

• Риск. bisect без чистого критерия (баг то воспроизводится, то нет из-за флакующего теста) даёт неверный результат; cherry-pick коммита, зависящего от других неперенесённых коммитов — ведёт к ошибкам сборки.