Навіщо командам історія: контроль версій без страху

Котокорм тримає свій сайт у репозиторії на GitHub. У підтримки питання: чому доставка тепер коштує 59 грн, а не 49? Маркетинг каже, що вони ні до чого. Без спільної історії це тиждень розпитувань.

Уяви звичну альтернативу: prices.xlsx, prices-new.xlsx, prices-final-v3.xlsx у спільній папці. Двоє редагують водночас, один затирає правки іншого, старі цифри зникають, і ніхто не знає, котра копія справжня.

Контроль версій (version control) розв'язує саме це. Він тримає один проєкт і зберігає кожен його стан окремим кроком. Кожен крок — це коміт (commit): він записує, хто його зробив, коли і коротке повідомлення, навіщо. Ланцюжок комітів — це історія проєкту.

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

Люди кажуть «Git» і «GitHub» так, ніби це одне слово. Насправді це дві різні речі, які працюють разом.

Git — це сама система контролю версій. Вона записує коміти й зберігає історію. Розробники запускають її на своїх ноутбуках і вводять команди в терміналі: git commit зберігає крок, git log показує історію, git push надсилає нові коміти до спільної копії проєкту.

GitHub — це сайт, який зберігає Git-репозиторії й додає командну роботу: pull requests, щоб пропонувати й обговорювати зміни, рев'ю, issues для задач і багів, релізи. Git — двигун, а GitHub — офіс, збудований навколо нього. Є й інші такі сайти, але Git під ними той самий.

Для продакта чи маркетолога це добра новина. Усе, що треба читати (файли, коміти, історію, pull requests), є у вебінтерфейсі GitHub, просто в браузері. Коли розробник згадує команду, корисно знати, що вона робить, але вводити її тобі не доведеться.

Проєкт разом з усією історією називається репозиторій (repository), коротко «репо». У Котокорму це catchow/website: шаблони сторінок, тексти, зображення й конфігураційний файл із цінами. Його основна лінія роботи — основна гілка main.

У цьому курсі історію малюють точками на лінії. Кожна точка — один коміт із повідомленням поруч. Час іде згори донизу: найстаріший коміт угорі, найновіший унизу. Щоб знайти, що сталося останнім, дивись на останню точку.

В історії Котокорму четверта точка каже «Raise delivery price to 59 UAH». Загадку підтримки розгадано за секунди, нікого не розпитуючи.

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

Коміт із ціною доставки називає автора: Daniel, веброзробник Котокорму. Коли його спитали в чаті, він ледь пригадав: кур'єрська служба підняла тарифи, і фінвідділ попросив перекласти це на доставку. Йому й не треба пам'ятати. Пам'ятає історія.

Git записує ті самі п'ять речей для кожного коміту, завжди:

• зміни у файлах;
• автора;
• дату й час;
• повідомлення коміту — коротку примітку, що змінилося і навіщо;
• унікальний ідентифікатор, хеш коміту, наприклад a41c09e.

Деяких речей у коміті немає, хоч ти й побачиш їх поруч на GitHub. Хто схвалив зміну, належить до pull request — функції GitHub. Чи зміна вже на сайті, залежить від викладання (деплою), якого Git не відстежує. Тож на питання «хто це погодив?» відповідь у pull request, а на «це вже на сайті?» — у команди чи в релізі, а не в коміті.

Кожен коміт отримує унікальний ідентифікатор — хеш коміту (commit hash). Git обчислює його з вмісту коміту, тож двох однакових хешів не буває. Повний хеш має 40 символів — цифри й літери від a до f; люди майже завжди наводять лише перші сім, як a41c09e, і цього досить, щоб указати на один коміт у проєкті.

Тому розробники й кидають хеші в чати й задачі: хеш — це точна адреса. На GitHub його можна вставити в пошук репозиторію або відкрити посилання, що закінчується на /commit/a41c09e, і ти потрапиш саме на цю зміну з автором, часом, повідомленням і diff. У терміналі те саме робить git show a41c09e.

Не плутай хеш з іншими назвами. Гілка має зрозумілу назву на кшталт main і рухається вперед, коли додається робота. Тег на кшталт v2.4.0 — зручна для людей мітка на одному коміті, зазвичай релізі. Хеш — власний ідентифікатор Git, і він ніколи не змінюється.

Звичний страх під час першого візиту на GitHub — що один неправильний клік покладе магазин. Не покладе. Читання нічого не змінює: відкривати файли, коміти, гілки й pull requests так само безпечно, як читати сторінку у вікі.

Робочий сайт змінюється лише через свідомий ланцюжок кроків. Хтось пропонує зміну в pull request, колега робить рев'ю, зміну зливають (merge) у main, а потім викладають (deploy) на сайт. У Котокормі кожен мердж у main спершу проходить рев'ю, тож випадковий клік відвідувача цей ланцюжок не обійде.

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

Коли коміт уже в main, команда його не стирає. Вона додає revert (відкат): новий коміт, що застосовує точно протилежну зміну. Поганий рядок прибирається, старий повертається, а історія показує і помилку, і виправлення — з автором і причиною для кожного.

Розробники роблять це командою git revert a41c09e, яка створює такий коміт-скасування. На GitHub у змердженого pull request є кнопка Revert: вона відкриває новий pull request, що скасовує всю зміну, і команда переглядає та мерджить його, як будь-який інший.

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

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

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

• Знайти, хто і навіщо. Підтримка питає, чому доставка коштує 59 грн; коміт називає Daniel і причину.
• Скасувати. Учорашній банер зламав мобільну верстку; revert повертає попередній стан.
• Працювати паралельно. Двоє розробників того самого дня змінюють різні сторінки, і ніхто не затирає іншого.
• Порівняти. Хочеш побачити, яким був текст сторінки доставки в березні; відкриваєш стару версію поруч із сьогоднішньою.

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

Ці самі завдання корисні й поза кодом. Коли тексти сайту живуть у репозиторії, а не в документі «v5-final», контент-команда має одну актуальну версію, чіткий запис правок і безпечний шлях назад.

На кожній сторінці репозиторію трапляються чотири об'єкти, кожен зі своєю маленькою іконкою. Запам'ятай їх зараз — вони повертатимуться в кожному уроці.

• Репозиторій (repository): проєкт з усією історією. Іконка схожа на книжку.
• Коміт (commit): один збережений крок з автором, часом і повідомленням. Іконка — точка на лінії.
• Гілка (branch): паралельна лінія роботи. Іконка — лінія, що розгалужується. main — прийнята версія, з якої будують сайт; гілкам пізніше буде присвячено цілий модуль.
• Тег (tag): постійна назва одного коміту, зазвичай версія на кшталт v2.4.0. Іконка схожа на цінник. Так команда каже: «ось саме цей коміт ми випустили».

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