Пошук в історії Git: коли змінився потрібний рядок

На сайті з’явився банер технічних робіт, але в задачі немає посилання на зміну. Пошук у поточних файлах знаходить maintenance-mode, проте не пояснює, коли цей маркер додали та що змінили поруч. Пошук в історії Git допомагає перейти від фрагмента тексту до конкретного коміту. Розберемо навчальний сценарій із файлом src/banner.js: спочатку знайдемо появу маркера, потім відокремимо її від пізнішої зміни умови.

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

Сформулюйте запитання до історії

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

Відкрийте термінал у каталозі дозволеної локальної копії проєкту. Потрібен встановлений Git; додаткові пакети й адміністративні права не потрібні. Перший запит перевіряє інструмент, другий показує корінь репозиторію, третій — чи є копія поверхневою. Команди виконуються з директорії цього репозиторію; перед наступними прикладами перейдіть у показаний корінь, щоб умовний шлях читався однозначно.

git --version
git rev-parse --show-toplevel
git rev-parse --is-shallow-repository

Якщо Git повідомляє, що це не репозиторій, не створюйте новий командою init: так ви не відновите втрачену історію. Знайдіть правильну робочу копію. Значення true в останній перевірці означає обмежену глибину доступної історії. Зафіксуйте це обмеження; завантаження відсутніх комітів є окремою мережевою операцією й не входить до наведеного маршруту читання.

Знайдіть зміну кількості входжень

Замініть maintenance-mode на потрібний несекретний фрагмент, а src/banner.js — на реальний шлях від кореня проєкту. Лапки зберігають рядок одним аргументом оболонки. Роздільник -- відокремлює шлях від параметрів; він не означає пошук у всіх файлах. Приклад обмежено одним файлом і комітами, доступними з поточного HEAD, тому він не відповідає на запитання про всі віддалені гілки.

git --no-pager log --no-ext-diff --no-textconv \
  --oneline -S'maintenance-mode' -- src/banner.js

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

Навчальний приклад: у першій зміні маркер з’явився один раз, у наступній залишився один раз, але умова навколо нього стала іншою. Пошук -S може показати додавання, але не таке переписування зі збереженою кількістю входжень. Не робіть висновок «рядок не змінювали» з відсутності другого результату. Наша мета — правильно обрати питання, а не зібрати найдовший список комітів.

Перевірте переписування та прочитайте патч

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

git --no-pager log --no-ext-diff --no-textconv \
  --oneline -G'maintenance-mode' -- src/banner.js

Зі списку виберіть ідентифікатор коміту та підставте його замість COMMIT у наступній команді. Це позначення для заміни, не готове ім’я ревізії. Використайте однозначний ідентифікатор із вашого результату й той самий реальний шлях. Команда покаже опис і патч файла; вона не застосовує зміни. Вимкнення зовнішнього diff і перетворювачів тексту робить приклад незалежнішим від локальних налаштувань перегляду.

git --no-pager show --no-ext-diff --no-textconv \
  COMMIT -- src/banner.js

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

Позначте межі висновку перед виправленням

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

Завершений результат — нотатка з фрагментом, шляхом, областю історії, комітом і поясненням побаченої зміни. Відокремте встановлене походження коду від гіпотези про збій. Для підтвердження поведінки потрібне окреме відтворення в тестовому середовищі. Не робіть reset, revert або checkout старих файлів у спільній робочій копії лише для перевірки припущення: це вже зміни, які потребують плану та збереження незавершеної роботи.

Висновок: -S допомагає шукати зміну кількості входжень, а -G — відповідні рядки патча; конкретну відповідь дає уважний перегляд знайденого коміту. Коли виправлення буде готове, використайте перевірку Git-коміту перед відправленням. Якщо історія проєкту не дає зрозумілого контексту, AriZone може допомогти локалізувати зміну й сформулювати перевірювану задачу без небезпечного відкату навмання.