Розробник виправив кнопку, але разом із потрібним кодом у репозиторій потрапили тимчасовий журнал і локальна конфігурація. Інший типовий сценарій: файл змінили після додавання до індексу, а коміт зберіг попередній варіант. Обидві ситуації легко пропустити, якщо орієнтуватися лише на успішний запуск сайту. Перевірка Git-коміту допомагає контролювати саме набір змін, який команда отримає для перегляду. Вона корисна для PHP, JavaScript, Python і будь-якого іншого вебпроєкту, де код зберігається у Git.
Три стани файлу, які не слід плутати
У звичайному робочому процесі варто розрізняти останній коміт, робочу директорію та індекс. Робоча директорія містить файли, які ви редагуєте. Індекс зберігає підготовлений набір для наступного коміту. Останній коміт дає попередню точку порівняння. Ці стани можуть відрізнятися навіть для одного файлу, тому наявність правильного коду в редакторі ще не підтверджує правильний склад майбутнього коміту.
Наприклад, ви додали файл стилів до індексу, а потім виправили в ньому відступ. Нове редагування не стає частиною підготовленого набору автоматично. Команда git diff показує зміни робочої директорії відносно індексу, а git diff --staged — підготовлені зміни відносно останнього коміту. Порожній результат першої команди не означає, що друга також буде порожньою. Це різні запитання до стану проєкту.
Зберігайте ці перевірки у короткому командному переліку, доступному поруч із документацією проєкту.
Розберіть склад змін до перегляду рядків
Почніть із git status у директорії потрібного репозиторію. Переконайтеся, що працюєте в очікуваній гілці, і перегляньте підготовлені, непідготовлені та невідстежувані файли. Невідстежуваний файл не потрапить до коміту, доки його не додано, але він може бути важливою частиною виправлення. Наприклад, новий шаблон потрібен для функції, хоча зміни контролера вже підготовлені. Зворотна проблема — доданий файл, який взагалі не стосується задачі.
Для кожного шляху поставте коротке запитання: чому він потрібен саме цьому виправленню? Відокремте зміну поведінки від випадкового форматування, експериментів і локальних налаштувань. Не видаляйте незрозумілі файли тільки заради чистого статусу: спочатку з’ясуйте їхнє походження. У спільній робочій директорії чужі незавершені зміни можуть бути потрібними іншому розробнику. Перевірка має допомогти сформувати коміт, а не знищити решту роботи.
Особливу увагу приділіть конфігурації середовища, дампам бази, журналам, архівам і завантаженим користувачами документам. Секрети не повинні опинятися в історії Git. Файл виключень допомагає уникати випадкового додавання невідстежуваних файлів, але не прибирає вже відстежуваний секрет із попередніх комітів. Якщо приватний ключ або пароль уже потрапив у репозиторій, потрібні відкликання відповідного доступу та окрема процедура роботи з історією.
Прочитайте підготовлений diff як майбутній рецензент
Перегляньте git diff --staged --stat, щоб оцінити масштаб, а потім повний git diff --staged. Зведення показує кількість змінених рядків, проте не пояснює сенс виправлення. Перевіряйте не лише додані рядки: видалений виклик, умова або обробник помилки можуть змінювати поведінку сильніше, ніж новий код. Для двійкових файлів текстовий diff не замінює відкриття й перевірку самого матеріалу.
Уявімо умовну зміну форми: кнопка тепер блокується на час запиту. Рецензенту важливо побачити не лише блокування, а й повернення доступності після помилки. Перевірте зв’язок між інтерфейсом, обробником відповіді та повідомленням користувачу. Якщо коміт змінює тільки щасливий сценарій, проблема може залишитися після розриву з’єднання. Такий перегляд відрізняється від простого пошуку друкарських помилок: він перевіряє завершеність рішення.
Команда git diff --staged --check може виявити певні проблеми з пробілами та маркери конфліктів у підготовлених змінах. Вона не доводить правильність програми й не замінює тестування. Опис цих режимів доступний в офіційній документації Git. Використовуйте команди перегляду як джерело доказів, а не як ритуал, після якого будь-який набір файлів вважається готовим.
Перевірте поведінку та залиште зрозумілий слід
Виберіть перевірки за характером задачі. Для зміни шаблону потрібен перегляд відповідної сторінки, для обчислення суми — перевірка очікуваних значень і крайніх випадків, для обробника помилки — відтворення помилкового сценарію. Запускайте інструменти, які вже прийняті в проєкті, та зважайте на їхній результат. Успішне форматування підтверджує оформлення коду, але не роботу бізнеслогіки. Невдалу перевірку не приховуйте за загальним формулюванням «усе протестовано».
Після виправлень повторно перегляньте статус та підготовлений diff: результати тестування іноді створюють службові файли, а додаткове редагування залишається поза індексом. Опис коміту має пояснювати результат для користувача або системи. Замість загального «оновлення» напишіть, яку поведінку змінено і чому. У супровідному описі зазначте виконані перевірки та відомі обмеження, щоб наступна людина могла оцінити роботу без усної передачі контексту.
Висновок: готовність коміту визначається узгодженістю його складу, поведінки та опису. Один завершений набір змін легше переглянути, ніж суміш кількох незв’язаних задач. Якщо команда регулярно губить контекст виправлень, варто впорядкувати процес технічної підтримки сайту. AriZone може допомогти узгодити практичний порядок перевірки змін і передачі релізів для вашого вебпроєкту.
Залиште коментар