git bisect шукає коміт, що вніс помилку, двійковим пошуком. Ви називаєте один «поганий» коміт (де баг є) і один «хороший» (де його ще не було), а Git щоразу переходить на середину проміжку й питає, чи є там баг.
git bisect start
git bisect bad # поточний коміт - зламаний
git bisect good v2.3.0 # у цьому релізі все працювало
# Git перемикається на коміт посередині
# перевіряєте й кажете:
git bisect good # або
git bisect bad
# ...через кілька кроків:
# a1b2c3d is the first bad commit
git bisect reset # повернутися, звідки почали
Серед 1000 комітів винуватця знайдено за ~10 перевірок.
Автоматично - якщо є команда, що відповідає «добре/погано» кодом виходу:
git bisect run php artisan test --filter=InvoiceTotalTest
Код 0 - коміт хороший, 1-127 (крім 125) - поганий, 125 - пропустити (наприклад, коміт не збирається).
Що допомагає bisect:
- Невеликі коміти, кожен з яких працює. Якщо коміт «напівготовий» і падає з іншої причини, bisect заплутається - такі коміти пропускають (
git bisect skip). - Тест, що відтворює баг, - його пишуть першим, а потім ганяють через
bisect run.
Знайшовши коміт, видно не лише рядок, а й контекст: повідомлення, задачу, автора - часто це пояснює, чому баг з'явився.
