Регресії є великою проблемою в індустрії програмного забезпечення. Але важко підтвердити це твердження реальними цифрами.

Існують деякі статистичні дані щодо програмних помилок загалом, наприклад, дослідження NIST 2002 року [1], в якому зазначалося:

А потім:

Зрештою, висновок почався з таких слів:

Існують й інші оцінки, які стверджують, що 80% витрат, повʼязаних з програмним забезпеченням, припадає на обслуговування [2].

Хоча, згідно з Вікіпедією [3]:

Але можна припустити, що вдосконалення наявного програмного забезпечення є дуже дорогим, оскільки потрібно стежити за регресіями. Принаймні, це зробило б вищезазначені дослідження узгодженими між собою.

Звичайно, певне програмне забезпечення розробляється, потім використовується протягом певного часу без значних покращень, а потім зрештою викидається. У цьому випадку, звичайно, регресії можуть не бути великою проблемою. Але з іншого боку, існує багато великого програмного забезпечення, яке постійно розробляється та підтримується протягом років або навіть десятків років багатьма людьми. І оскільки часто є багато людей, які залежать (іноді критично) від такого програмного забезпечення, регресії є справді великою проблемою.

Одним із таких програмних продуктів є ядро Linux. Якщо ж розглянути ядро Linux, то можна побачити, що на боротьбу з регресіями витрачається чимало часу та зусиль. Цикл випуску починається з двотижневого періоду злиття змін. Потім позначається перша версія-кандидат у випуск (rc). Після цього, до остаточного випуску, з’являється ще близько 7–8 версій rc з інтервалом приблизно в один тиждень між кожною з них.

Період між першим кандидатом на випуск та остаточним випуском повинен бути присвячений тестуванню кандидатів та усуненню помилок, а особливо регресій. Цей період становить понад 80 % тривалості циклу випуску. Але на цьому боротьба ще не закінчується, адже вона, звісно, триває й після випуску.

А ось що каже Інго Молнар (відомий розробник ядра Linux) про своє використання git bisect:

Тож розробники постійно борються з регресіями, і справді добре відомо, що помилки слід виправляти якомога швидше, тобто одразу після їх виявлення. Ось чому добре мати хороші інструменти для цього.

Отже, які ж інструменти використовуються для боротьби з регресіями? Вони майже такі ж, як і ті, що використовуються для боротьби зі звичайними помилками. Єдиними специфічними інструментами є набори тестів та інструменти, подібні до "git bisect".

Набори тестів — це чудова річ. Але коли їх використовують окремо, передбачається, що всі тести перевіряються після кожного коміту. Це означає, що вони не надто ефективні, оскільки багато тестів виконуються без будь-якого корисного результату, а також страждають від комбінаторного вибуху.

Насправді проблема полягає в тому, що великі розробники програмного забезпечення часто мають багато різних опцій конфігурації, і кожен тестовий випадок повинен бути успішним для кожної конфігурації після кожного коміту. Тож, якщо у вас є для кожного релізу: N конфігурацій, M комітів та T тестових випадків, вам слід виконати:

де N, M та T зростають із розміром вашого програмного забезпечення.

Тож дуже скоро повністю все протестувати не вдасться.

А якщо деякі помилки прослизнуть крізь ваш набір тестів, ви можете додати до нього новий тест. Але якщо ви хочете використати свій новий, вдосконалений набір тестів, щоб виявити, де саме прослизнула помилка, вам доведеться або імітувати процес бісекції, або, можливо, просто перевіряти кожен коміт у зворотному порядку, починаючи з того «помилкового» коміту, що у вас є, що може виявитися дуже марнотратним.

Перша субкоманда "git bisect", яку потрібно використати, це "git bisect start", щоб розпочати пошук. Потім необхідно встановити межі, щоб обмежити простір комітів. Зазвичай це робиться шляхом надання одного "поганого" та принаймні одного "правильного" коміту. Їх можна передати під час початкового виклику "git bisect start" ось так:

або їх можна встановити за допомогою:

і:

де BAD, GOOD та COMMIT — це імена, які можна перетворити на коміт.

Тоді "git bisect" перевірить вибраний коміт і попросить користувача протестувати його, ось так:

Зверніть увагу, що приклад, який ми будемо використовувати, є насправді дуже простим: ми шукатимемо перший коміт із версією на кшталт «2.6.26-something», тобто той коміт, у Makefile найвищого рівня якого є рядок «SUBLEVEL = 26». Це простий приклад, оскільки існують кращі способи знайти цей комміт за допомогою Git, ніж використання «git bisect» (наприклад, «git blame» або «git log -S<string>»).

На даний момент існує два основних способи керування пошуком. Він може здійснюватися вручну користувачем або автоматично за допомогою скрипта чи команди.

Якщо користувач керує цим, то на кожному кроці пошуку йому доведеться перевіряти поточний коміт і визначати, чи він "хороший" чи "поганий", використовуючи команди "git bisect good" або "git bisect bad" відповідно, які були описані вище. Наприклад:

І після ще кількох таких кроків, "git bisect" врешті-решт знайде перший поганий коміт:

На цьому етапі ми можемо побачити, що робить коміт, перевірити його (якщо він ще не активний) або погратися з ним, наприклад:

А коли ми закінчимо, ми можемо використати "git bisect reset", щоб повернутися до гілки, в якій ми були перед початком бісекції:

Інший спосіб керувати процесом бісекції — це наказати "git bisect" запускати скрипт або команду на кожному кроці бісекції, щоб дізнатися, чи є поточний коміт "хорошим" чи "поганим". Для цього ми використовуємо команду "git bisect run". Наприклад:

У цьому прикладі ми передали "grep ^SUBLEVEL = 25 Makefile" як параметр для "git bisect run". Це означає, що на кожному кроці буде запущено передану нами команду grep. І якщо вона завершиться з кодом 0 (це означає успіх), то git bisect позначить поточний стан як "хороший". Якщо ж вона завершиться з кодом 1 (або будь-яким кодом від 1 до 127, включаючи, крім спеціального коду 125), то поточний стан буде позначено як "поганий".

Код виходу між 128 та 255 є спеціальним для "git bisect run". Він змушує його негайно зупинити процес бісекції. Це корисно, наприклад, якщо передана команда виконується занадто довго, оскільки ви можете завершити її сигналом, і це зупинить процес бісекції.

Це також може бути корисним у скриптах, що передаються команді "git bisect run" для "exit 255", якщо виявлено якусь дуже аномальну ситуацію.

Іноді трапляється, що поточний стан неможливо перевірити, наприклад, якщо він не компілюється через помилку, яка на той момент цьому перешкоджала. Саме для цього і призначений спеціальний код виходу 125. Він повідомляє команді "git bisect run", що поточний коміт слід позначити як нетестований, а також вибрати та перевірити інший.

Якщо процес бісекції виконується вручну, ви можете використати "git bisect skip" для виконання того ж завдання. (Фактично, спеціальний код виходу 125 змушує "git bisect run" використовувати "git bisect skip" у фоновому режимі.)

Або, якщо ви хочете мати більше контролю, ви можете перевірити поточний стан, використовуючи, наприклад, "git bisect visualize". Це запустить gitk (або "git log", якщо змінна середовища DISPLAY не встановлена), щоб допомогти вам знайти кращу точку бісекції.

У будь-якому разі, якщо у вас є рядок неперевірюваних комітів, може статися так, що регресія, яку ви шукаєте, була введена одним із цих неперевірюваних комітів. У цьому випадку неможливо точно сказати, який коміт вніс регресію.

Отже, якщо ви використали "git bisect skip" (або сценарій запуску завершився зі спеціальним кодом 125), ви могли отримати такий результат:

Якщо ви хочете показати іншим людям процес бісекції, ви можете отримати журнал, наприклад:

І його можна відтворити за допомогою:

Оскільки коміти Git утворюють спрямований ациклічний граф (DAG), знайти найкращий коміт з бісекцією для тестування на кожному кроці не так просто. У будь-якому разі, Лінус знайшов та реалізував «дійсно дурний» алгоритм, пізніше вдосконалений Джуніо Хамано, який працює досить добре.

Отже, алгоритм, який використовується "git bisect" для знаходження найкращого коміту з бісекцією, коли немає пропущених комітів, такий:

1) зберігати лише ті коміти, які:

a) є предком "поганого" коміту (включно з самим "поганим" комітом), b) не є предками "хорошого" коміту (за винятком "хороших" комітів).

Це означає, що ми позбавляємося нецікавих комітів у DAG.

Наприклад, якщо ми почнемо з такого графа:

де B — це «поганий» коміт, «G» — «хороші» коміти, а W, X та Y — інші коміти, після цього першого кроку ми отримаємо наступний граф:

Отже, будуть збережені лише коміти W та B. Оскільки коміти X та Y будуть видалені за правилами a) та b) відповідно, а також оскільки коміти G також видаляються за правилом b).

Зверніть увагу для користувачів Git, що це еквівалентно збереженню лише коміту, заданого:

Також зверніть увагу, що нам не потрібно, щоб коміти, які зберігаються, були нащадками "хорошого" коміту. Тому в наступному прикладі будуть збережені коміти W та Z:

2) починаючи з "хороших" кінців графа, повʼязати з кожним комітом кількість його предків плюс один

Наприклад, з наступним графом, де H — це «поганий» коміт, а A та D — деякі батьки деяких «хороших» комітів:

це дасть:

3) асоціювати з кожним комітом: min(X, N - X)

де X — це значення, повʼязане з комітом на кроці 2), а N — загальна кількість комітів у графі.

У наведеному вище прикладі ми маємо N = 8, тому це дасть:

4) Найкраща точка поділу — це коміт з найбільшим повʼязаним номером

Отже, у наведеному вище прикладі найкращою точкою бісекції є коміт C.

5) Зверніть увагу, що для пришвидшення роботи алгоритму реалізовано деякі скорочення

Оскільки N нам відоме з самого початку, ми знаємо, що min(X, N - X) не може бути більшим за N/2. Тому, під час кроків 2) та 3), якщо ми повʼяжемо N/2 з комітом, то знатимемо, що це найкраща точка бісекції. Тож у цьому випадку ми можемо просто зупинити обробку будь-якого іншого коміту та повернути поточний коміт.

Для будь-якого графу комітів ви можете побачити кількість, повʼязану з кожним комітом, використовуючи "git rev-list --bisect-all".

Наприклад, для наведеного вище графу, команда типу:

виведе щось на кшталт:

Спочатку визначимо "найкращу точку бісекції". Ми скажемо, що коміт X є найкращою точкою бісекції або найкращим комітом бісекції, якщо знання його стану ("добрий" чи "поганий") дає якомога більше інформації про те, чи є стан коміту "добрим" чи "поганим".

Це означає, що найкращими коммітами з бісекцією є ті, де наступна функція є максимальною:

де information_if_good(X) — це інформація, яку ми отримуємо, якщо X є добрим, а information_if_bad(X) — це інформація, яку ми отримуємо, якщо X є поганим.

Тепер припустимо, що існує лише один «перший поганий коміт». Це означає, що всі його нащадки є «поганими», а всі інші коміти — «хорошими». Також припустимо, що всі коміти мають однакову ймовірність бути хорошими чи поганими або бути першим поганим комітом, тому знання стану c комітів завжди дає однакову кількість інформації незалежно від того, де саме на графі знаходяться ці c комітів і яким є значення c. (Отже, ми припускаємо, що те, що ці коміти, наприклад, знаходяться у гілці або поблизу хорошого чи поганого коміту, не дає більше чи менше інформації).

Також припустимо, що у нас є очищений граф, як той, що був після кроку 1) у вищезгаданому алгоритмі бісекції. Це означає, що ми можемо виміряти отриману інформацію з точки зору кількості комітів, які можна видалити з графа.

І візьмемо коміт X на графі.

Якщо X виявляється «хорошим», то ми знаємо, що всі його предки «хороші», тому ми хочемо сказати, що:

І це правда, тому що на кроці 1) b) ми видаляємо предків "хороших" комітів.

Якщо X виявляється «поганим», то ми знаємо, що всі його нащадки «погані», тому ми хочемо сказати, що:

Але це неправильно, тому що на кроці 1) a) ми зберігаємо лише предків поганого коміту. Тож ми отримуємо більше інформації, коли коміт позначено як "поганий", оскільки ми також знаємо, що предки попереднього "поганого" коміту, які не є предками нового "поганого" коміту, не є першим поганим комітом. Ми не знаємо, чи вони хороші, чи погані, але ми знаємо, що вони не є першим поганим комітом, тому що вони не є предками нового "поганого" коміту.

Отже, коли коміт позначено як "поганий", ми знаємо, що можемо видалити всі коміти в графі, окрім тих, що є предками нового "поганого" коміту. Це означає, що:

де N — кількість комітів у (очищеному) графі.

Отже, зрештою це означає, що для знаходження найкращих комітів бісекції нам слід максимізувати функцію:

І це добре, тому що на кроці 2) ми обчислюємо number_of_ancestors(X) і тому на кроці 3) ми обчислюємо f(X).

Візьмемо для прикладу наступний граф:

Якщо ми обчислимо на ньому таку неоптимальну функцію:

отримуємо:

але за допомогою алгоритму, який використовується git bisect, ми отримуємо:

Отже, ми обрали G, H, K або L як найкращу точку бісекції, що краще, ніж F. Тому що, якщо, наприклад, L поганий, то ми знатимемо не тільки те, що L, M та N погані, але й те, що G, H, I та J не є першим поганим комітом (оскільки ми припускаємо, що є лише один перший поганий коміт, і він має бути предком L).

Отже, поточний алгоритм видається найкращим з можливих, враховуючи те, що ми спочатку припускали.

Коли деякі коміти пропущено (за допомогою "git bisect skip"), алгоритм бісекції однаковий для кроків 1) – 3). Але тоді ми використовуємо приблизно такі кроки:

6) сортувати коміт за зменшенням повʼязаного значення

7) якщо перший коміт не був пропущений, ми можемо повернути його та зупинитися тут

8) інакше відфільтрувати всі пропущені коміти у відсортованому списку

9) використовувати генератор псевдовипадкових чисел (ГПВЧ) для генерації випадкового числа від 0 до 1

10) помножте це випадкове число на його квадратний корінь, щоб змістити його до 0

11) помножте результат на кількість комітів у відфільтрованому списку, щоб отримати індекс у цьому списку

12) повернути коміт за обчисленим індексом

Після кроку 7) (в алгоритмі пропуску), ми могли б перевірити, чи був пропущений другий коміт, і повернути його, якщо це не так. І насправді це був алгоритм, який ми використовували з моменту розробки "git bisect skip" у версії Git 1.5.4 (випущеній 1 лютого 2008 року) до версії Git 1.6.4 (випущеної 29 липня 2009 року).

Але Інго Молнар та Х. Пітер Анвін (ще один відомий розробник ядра Linux) скаржилися, що іноді найкращі точки поділу знаходяться в області, де всі коміти неможливо перевірити. І в цьому випадку користувача просили протестувати багато неперевірюваних комітів, що може бути дуже неефективно.

Дійсно, неперевірювані коміти часто є неперевірюваними, тому що поломка була внесена одного разу, і ця поломка була виправлена лише після того, як було введено багато інших комітів.

Звичайно, ця поломка здебільшого не повʼязана з поломкою, яку ми намагаємося знайти в графі комітів. Але вона заважає нам дізнатися, чи присутня цікава "погана поведінка", чи ні.

Отже, це факт, що коміти поруч із неперевірюваним комітом мають високу ймовірність того, що самі будуть неперевірюваними. І найкращі коміти з бісекцією також часто знаходяться разом (завдяки алгоритму бісекції).

Ось чому погана ідея просто вибрати наступний найкращий непропущений коміт бісекції, коли перший вже пропущено.

Ми виявили, що більшість комітів на графі можуть давати досить багато інформації після тестування. А коміти, які в середньому не дають багато інформації, це ті, що знаходяться поруч із хорошими та поганими комітами.

Тож використання генератора випадкових чисел (ГВЧ) з упередженням на користь комітів, віддаляючи їх від хороших та поганих, виглядало гарним вибором.

Одним очевидним покращенням цього алгоритму було б пошук коміта, який має повʼязане значення поблизу одного з найкращих комітів з бісекцією, і який знаходиться на іншій гілці, перед використанням генератора випадкових чисел. Тому що, якщо такий коміт існує, то він навряд чи буде неперевірюваним, тому, ймовірно, надасть більше інформації, ніж майже випадково вибраний.

В алгоритмі бесекції є ще одне налаштування, яке не було описано у вищезгаданому розділі "алгоритм бісекції".

У попередніх прикладах ми припускали, що "хороші" коміти є предками "поганого" коміту. Але це не є вимогою "git bisect".

Звісно, «поганий» коміт не може бути предком «хорошого» коміту, адже предки хороших комітів мають бути «хорошими». І всі «хороші» коміти повинні бути пов’язані з «поганим» комітом. Вони не можуть перебувати на гілці, яка не має зв’язку з гілкою «поганого» коміту. Але можливо, що хороший коміт пов’язаний з поганим комітом, але при цьому не є ані його предком, ані його нащадком.

Наприклад, може бути гілка "main" та гілка "dev", яка була відгалужена від гілки main у коміті з іменем "D", ось так:

Коміт "D" називається "базою злиття" для гілок "main" та "dev", оскільки він є найкращим спільним предком для цих гілок при злиття.

Тепер припустимо, що коміт J поганий, а коміт G хороший, і що ми застосовуємо алгоритм бісекції, як це було описано раніше.

Як описано в кроці 1) b) алгоритму бісекції, ми видаляємо всіх предків хороших комітів, оскільки вони також повинні бути хорошими.

Тож у нас залишиться лише:

Але що станеться, якщо перший поганий коміт — це «B», і якщо його було виправлено в гілці «main» комітом «F»?

Результатом такої бісекції було б те, що ми виявили б, що H — це перший поганий коміт, хоча насправді це B. Тож це було б неправильно!

І так, на практиці може трапитися так, що люди, які працюють над однією гілкою, не знають, що люди, які працюють над іншою гілкою, виправили помилку! Також може статися так, що F виправила більше однієї помилки, або що це повернення якоїсь великої розробки, яка не була готова до випуску.

Насправді, команди розробників часто підтримують як гілку розробки, так і гілку обслуговування, і їм було б досить легко, якби "git bisect" працював, коли вони хочуть розділити регресію на гілці розробки, яка не знаходиться на гілці обслуговування. Вони повинні мати можливість розпочати бісекцію, використовуючи:

Щоб увімкнути цю додаткову зручну функцію, коли починається бісекція, і деякі хороші коміти не є предками поганого коміта, ми спочатку обчислюємо бази злиття між поганим та хорошим комітами та обираємо ці бази злиття як перші коміти, які будуть перевірені та протестовані.

Якщо трапляється, що одна з баз злиття є поганою, то процес бісекції зупиняється з повідомленням типу:

де BBBBBB — це хеш sha1 поганої бази злиття, а [GGGGGG,…​] — це список sha1 хороших комітів, розділений комами.

Якщо деякі з баз злиття пропущено, процес бісекції продовжується, але для кожної пропущеної бази злиття виводиться наступне повідомлення:

де BBBBBB — це хеш sha1 поганого коміту, MMMMMM — це хеш sha1 бази злиття, яка пропускається, а [GGGGGG,…​] — це список sha1 хороших комітів, розділений комами.

Отже, якщо немає поганої бази злиття, процес бісекції продовжується як завжди після цього кроку.

Якщо у вас є набір тестів і ви використовуєте git bisect, то перевіряти, чи всі тести проходять успішно після кожного коміту, стає не так важливо. Хоча, звичайно, варто проводити певні перевірки, щоб уникнути надмірної кількості збіїв, оскільки це може ускладнити пошук інших помилок за допомогою bisect.

Ви можете зосередити свої зусилля на перевірці кількох моментів (наприклад, rc та бета-релізів), чи всі T-тести проходять успішно для всіх N-конфігурацій. А коли деякі тести не проходять успішно, ви можете використовувати "git bisect" (або краще "git bisect run"). Отже, вам слід виконати приблизно так:

де c — кількість раундів тестування (тож це невелика константа), а та b — співвідношення кількості помилок на коміт (сподіваємося, що це також невелика константа).

Тож, звісно, набагато краще, оскільки це O(N * T) проти O(N * T * M), якщо ви тестуватимете все після кожного коміту.

Це означає, що тестові набори добре підходять для запобігання появі деяких помилок, а також вони досить добре підходять для того, щоб сказати вам, що у вас є деякі помилки. Але вони не настільки добре підходять для того, щоб сказати вам, де саме були впроваджені ті чи інші помилки. Щоб ефективно сказати вам про це, потрібен git bisect.

Ще одна приємна річ із наборами тестів полягає в тому, що коли у вас є один, ви вже знаєте, як тестувати на погану поведінку. Тож ви можете використовувати ці знання для створення нового тестового випадку для "git bisect", коли зʼявляється регресія. Таким чином, буде легше розділити помилку та виправити її. А потім ви можете додати щойно створений тестовий випадок до свого набору тестів.

Отже, якщо ви знаєте, як створювати тестові випадки та як застосовувати метод бісекції, ви потрапите у замкнуте коло:

більше тестів ⇒ легше створювати тести ⇒ легше робити бісекцію ⇒ більше тестів

Отже, набори тестів і «git bisect» — це взаємодоповнювальні інструменти, які при спільному використанні виявляються дуже потужними та ефективними.

Ви можете дуже легко автоматично перевіряти непрацюючі збірки методом бісекції, використовуючи щось на зразок:

Наприклад:

З іншого боку, якщо ви робите це часто, то варто мати скрипти, щоб уникнути надмірного набору тексту.

Ось приклад сценарію, дещо зміненого з реального сценарію, який використовує Джуніо Хамано [4].

Цей скрипт можна передати команді "git bisect run", щоб знайти коміт, який вніс регресію продуктивності:

Зрозуміло, що гарною ідеєю не є створення комітів зі змінами, які свідомо ламають систему, навіть якщо деякі інші коміти пізніше виправлять ці поломки.

Також гарною ідеєю при використанні будь-якої системи контролю версій (VCS) є мати лише одну невелику логічну зміну в кожному коміті.

Чим менші зміни у вашому коміті, тим ефективнішим буде "git bisect". І вам, ймовірно, знадобиться "git bisect" рідше, оскільки невеликі зміни легше переглянути, навіть якщо їх переглядає лише комітер.

Ще одна гарна ідея — мати гарні повідомлення про коміти. Вони можуть бути дуже корисними для розуміння, чому були внесені деякі зміни.

Ці загальні рекомендації дуже корисні, якщо ви часто робите бісекцію.

Перші злиття самі по собі можуть призвести до деяких регресій, навіть якщо для злиття не потрібне вирішення конфліктів у вихідному коді. Це пояснюється тим, що семантична зміна може відбутися в одній гілці, навіть якщо інша гілка про це не знає.

Наприклад, одна гілка може змінити семантику функції, тоді як інша гілка додасть більше викликів до тієї ж функції.

Ситуація значно ускладнюється, якщо для усунення конфліктів доводиться виправляти багато файлів. Саме тому такі злиття називають «злиттями-лиходіями». Вони можуть значно ускладнити виявлення регресій. Навіть знання про перший помилковий коміт може ввести в оману, якщо це саме таке злиття, адже користувачі можуть помилково вважати, що помилка виникла через неправильне вирішення конфлікту, хоча насправді вона пов’язана із семантичною зміною в одній із гілок.

У будь-якому разі, команду «git rebase» можна використовувати для вирівнювання історії. Це можна зробити або для того, щоб взагалі уникнути злиття, або для того, щоб проводити бісекцію на лінійній історії замість нелінійної, оскільки це має надати більше інформації у разі семантичних змін в одній з гілок.

Злиття також можна спростити, використовуючи менші гілки або багато тематичних гілок замість лише довгих гілок, повʼязаних з версіями.

А тестування можна проводити частіше у спеціальних гілках інтеграції, таких як linux-next для ядра Linux.

Спеціальний робочий процес для обробки регресій може дати чудові результати.

Ось приклад робочого процесу, який використовує Андреас Ерікссон:

А ось що Андреас сказав про цей робочий процес [5]:

Очевидно, що цей робочий процес використовує замкнене коло між наборами тестів та "git bisect". Фактично, це робить його стандартною процедурою для роботи з регресією.

В інших повідомленнях Андреас каже, що вони також використовують "найкращі практики", описані вище: невеликі логічні коміти, тематичні розгалуження, відсутність злиття з метою покращення бісекційності графа комітів, роблячи його легшим та кориснішим.

Отже, хороший робочий процес має бути розроблений навколо вищезазначених пунктів. Це робить бісекцію простішою, кориснішою та стандартнішою.

Одна перевага "git bisect" полягає в тому, що це не лише інструмент для розробників. Його можуть ефективно використовувати фахівці з контролю якості або навіть кінцеві користувачі (якщо вони мають доступ до вихідного коду або до всіх збірок).

У списку розсилки ядра Linux в якийсь момент точилася дискусія про те, чи нормально завжди просити кінцевого користувача робити бісекцію, і були наведені дуже вагомі аргументи на підтримку точки зору, що це нормально.

Наприклад, Девід Міллер написав [6]:

Це означає, що часто «дешевше», якщо це можуть зробити фахівці з контролю якості або кінцеві користувачі.

Цікаво також те, що кінцеві користувачі, які повідомляють про помилки (або фахівці з контролю якості, які відтворили помилку), мають доступ до середовища, де виникає помилка. Тому вони часто можуть легше відтворити регресію. А якщо вони можуть виконати бісекцію, то з середовища, де виникає помилка, буде отримано більше інформації, а це означає, що помилку буде легше зрозуміти, а потім виправити.

Для проєктів з відкритим кодом це може бути гарним способом отримати більше корисних внесків від кінцевих користувачів та ознайомити їх із заходами з контролю якості та розробки.

У деяких випадках, наприклад, для розробки ядра, може бути доцільно розробити складні скрипти, щоб мати змогу повністю автоматизувати процес виконання бісекції.

Ось що каже Інґо Молнар з цього приводу [7]:

Ми бачили, що тестові набори та git bisect є дуже потужними, коли використовуються разом. Вони можуть бути ще потужнішими, якщо ви зможете поєднати їх з іншими системами.

Наприклад, деякі набори тестів можуть запускатися автоматично вночі з деякими незвичайними (або навіть випадковими) конфігураціями. А якщо набір тестів виявляє регресію, то "git bisect" може бути автоматично запущений, а його результат може бути надісланий електронною поштою автору першого поганого коміту, знайденого "git bisect", і, можливо, іншим людям також. А також може бути автоматично створений новий запис у системі відстеження помилок.

Раніше ми бачили, що "git bisect skip" тепер використовує генератор випадкових чисел (PNS), щоб спробувати уникнути областей у графі комітів, де коміти неможливо перевірити. Проблема полягає в тому, що іноді перший поганий коміт знаходиться в області, яку неможливо перевірити.

Для спрощення розмови припустимо, що неперевірена ділянка — це простий ланцюжок комітів, який утворився внаслідок збою, спричиненого одним комітом (назвемо його BBC — «бісекційний збійний коміт»), а згодом виправлений іншим (назвемо його BFC — «бісекційний виправний коміт»).

Наприклад:

де ми знаємо, що Y — хороший варіант, а BFC — поганий, і де BBC та X1–X6 неперевірювані.

У цьому випадку, якщо ви виконуєте бісекцію вручну, можна створити спеціальну гілку, яка починається безпосередньо перед BBC. Першим комітом у цій гілці має бути BBC, до якого було об’єднано BFC. А інші коміти в гілці мають бути комітами між BBC і BFC, перебазованими на перший коміт гілки, а також комітом після BFC, який також перебазується на ньому.

Наприклад:

де коміти, зазначені ', були перебазовані.

Ви можете легко створити таку гілку за допомогою Git, використовуючи інтерактивне перебазування.

Наприклад, використовуючи:

а потім переміщення BFC після BBC та його знищення.

Після цього ви можете почати розбирати гілку як завжди в новій гілці, і врешті-решт ви повинні знайти перший поганий коміт.

Наприклад:

Якщо ви використовуєте "git bisect run", ви можете використати те саме ручне виправлення, що й вище, а потім запустити ще один "git bisect run" у спеціальній гілці. Або, як зазначено на сторінці довідки "git bisect", скрипт, переданий до "git bisect run", може застосувати латку перед компіляцією та тестуванням програмного забезпечення [8]. Латка має перетворити поточні неперевірювані коміти на тестові. Таким чином, тестування призведе до "хороших" або "поганих", і "git bisect" зможе знайти перший поганий коміт. І скрипт не повинен забувати видалити латку після завершення тестування перед виходом зі скрипта.

(Зверніть увагу, що замість латки ви можете використовувати "git cherry-pick BFC" для застосування виправлення, і в цьому випадку вам слід використовувати "git reset --hard HEAD^", щоб скасувати cherry-pick після тестування та перед поверненням зі скрипта.)

Але вищезазначені способи обходу нетестованих областей трохи незграбні. Використання спеціальних гілок є зручним, оскільки розробники можуть використовувати ці гілки спільно, як звичайні гілки, але є ризик того, що люди отримають багато таких гілок. І це порушує нормальний робочий процес "git bisect". Отже, якщо ви хочете використовувати "git bisect run" повністю автоматично, вам потрібно додати спеціальний код у ваш скрипт, щоб перезапустити бісекцію у спеціальних гілках.

У будь-якому разі, у наведеному вище прикладі спеціальної гілки можна помітити, що коміти Z' та Z повинні вказувати на той самий стан вихідного коду (те саме "дерево" мовою git). Це тому, що Z' є результатом застосування тих самих змін, що й Z, просто в дещо іншому порядку.

Отже, якби ми могли просто "замінити" Z на Z' під час бісекції, то нам не потрібно було б нічого додавати до скрипта. Це б працювало для будь-кого в проєкті, хто спільно використовує спеціальні гілки та заміни.

З наведеним вище прикладом це дасть:

Ось чому була створена команда "git replace". Технічно вона зберігає заміни "refs" в ієрархії "refs/replace/". Ці "refs" схожі на гілки (які зберігаються в "refs/heads/") або теги (які зберігаються в "refs/tags"), а це означає, що їх можна автоматично використовувати як гілки або теги між розробниками.

"git replace" — це дуже потужний механізм. Його можна використовувати для виправлення комітів у вже випущеній історії, наприклад, для зміни повідомлення коміта або автора. А також його можна використовувати замість git "grafts" для звʼязування репозиторію з іншим старим репозиторієм.

Фактично, саме ця остання функція «продала» його спільноті Git, тому зараз він знаходиться в «головній» гілці репозиторію Git і має бути випущений у Git 1.6.5 у жовтні або листопаді 2009 року.

Одна з проблем з "git replace" полягає в тому, що наразі він зберігає всі посилання на заміни в "refs/replace/", але, можливо, було б краще, якби посилання на заміни, корисні лише для бісекції, знаходилися в "refs/replace/bisect/". Таким чином, посилання на заміни можна було б використовувати лише для бісекції, тоді як інші посилання безпосередньо в "refs/replace/" використовувалися б майже постійно.

Ще одним можливим покращенням "git bisect" було б додавання певної надмірності до виконаних тестів, щоб зробити відстеження спорадичних помилок надійнішим.

Це було запропоновано деякими розробниками ядра, оскільки деякі помилки, які називаються спорадичними помилками, не зʼявляються у всіх збірках ядра, оскільки вони дуже залежать від виводу компілятора.

Ідея полягає в тому, що кожні 3 тести, наприклад, "git bisect", можуть попросити користувача протестувати коміт, який вже був визнаний "хорошим" або "поганим" (оскільки один з його нащадків або один з його предків був визнаний "хорошим" або "поганим" відповідно). Якщо трапляється, що коміт раніше був неправильно класифікований, то бісекцію можна перервати раніше, сподіваємося, перш ніж буде допущено забагато помилок. Тоді користувачеві доведеться подивитися, що сталося, а потім перезапустити бісекцію, використовуючи фіксований журнал бісекції.

На Github вже існує проєкт під назвою BBChop, створений Еальдвульфом Вуффінгою, який робить щось подібне, використовуючи баєсівську теорію пошуку [9]:

Але BBChop незалежний від будь-якої системи керування версіями, і користувачам Git було б простіше мати щось інтегроване в Git.