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

Є деякі цифри щодо бактерій загалом, як-от дослідження NIST 2002 року [1], яке говорить:

А потім:

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

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

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

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

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

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

Час між першим релізом rc та фінальним релізом має бути використаний для тестування 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-щось", тобто коміт, у якого є рядок "SUBLEVEL = 26" у Makefile верхнього рівня. Це іграшковий приклад, оскільки є кращі способи знайти цей коміт за допомогою Git, ніж використання "git bisect" (наприклад, "git blame" або "git log -S<рядок>").

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

Якщо користувач керує цим, то на кожному кроці пошуку йому доведеться перевіряти поточний коміт і визначати, чи він "хороший" чи "поганий", використовуючи команди "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) скаржилися, що іноді найкращі точки поділу знаходяться в області, де всі коміти неможливо перевірити. І в цьому випадку користувача просили протестувати багато неперевірюваних комітів, що може бути дуже неефективно.

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

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

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

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

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

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

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

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

У попередніх прикладах ми припускали, що "хороші" коміти є предками "поганого" коміту. Але це не є вимогою "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, тоді перевірка успішності всіх тестів після кожного коміту стає менш важливою. Хоча, звісно, ймовірно, гарною ідеєю буде мати деякі перевірки, щоб уникнути порушень надто великої кількості речей, оскільки це може ускладнити розділення інших помилок.

Ви можете зосередити свої зусилля на перевірці кількох моментів (наприклад, 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 від bisect breaking commit — коміт з розривом пополам), а пізніше виправлений іншим (назвемо його BFC від bisect fixing commit — коміт з розривом пополам).

Наприклад:

де ми знаємо, що 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.