Git для продакт-менеджерів простими словами

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

Швидкий приклад: чи вийшло виправлення в чекауті?

Котокорм, інтернет-магазин кормів для тварин, підняв поріг безкоштовної доставки з 800 до 1000 грн. На сторінці оформлення замовлення досі написано «Free delivery from 800 UAH», і збиті з пантелику клієнти пишуть у підтримку. У понеділок Sofia, продакт-менеджерка, просить веброзробника Daniel виправити текст. У четвер підтримка питає її, чи все вже виправлено, бо на сайті досі старе число.

Звичний хід — написати Daniel і чекати. Натомість Sofia відкриває репозиторій catchow/website:

Знаходить файл. Шукає в репозиторії фразу «Free delivery from» і потрапляє у pages/checkout.html.
Відкриває його історію. Кнопка History («історія») у файлі показує всі коміти, які його змінювали, найновіші вгорі. Перший у списку: «Fix free delivery threshold on checkout (#142)», автор Daniel, два дні тому.
Читає зміну. На сторінці коміту видно, що саме замінили (блок нижче).
Іде за посиланням. #142 веде на pull request (PR), тобто сторінку з пропозицією зміни. На ньому позначка, що його змерджено в main — основну гілку з прийнятою версією сайту.
Перевіряє реліз. Котокорм викладає сайт із релізів, позначених тегами. Останній, v2.4.0, опубліковано минулої п'ятниці, коли виправлення ще не існувало.

- <p class="hint">Free delivery from 800 UAH</p>
+ <p class="hint">Free delivery from 1000 UAH</p>

Отже, у коді текст виправлено, але до сайту він ще не дійшов. За кілька хвилин Sofia відповідає підтримці: «Виправлено, з'явиться на сайті з наступним релізом». А в повідомленні для Daniel уже не «що там із текстом у чекауті?», а «#142 змерджено, але у v2.4.0 його немає. Коли наступний реліз?» Відповідь займає один рядок: у п'ятницю вранці, v2.4.1.

Шість термінів простими словами

Термін	Що це	Що це каже продакту
Репозиторій	Папка проєкту разом з усією історією змін	Єдине місце, де живе продукт і його минуле
Коміт	Один збережений крок: зміна, автор, дата, повідомлення й унікальний ідентифікатор (хеш)	Хто, що і коли змінив
Гілка	Паралельна лінія комітів, де йде робота, не зачіпаючи `main`	Робота в процесі, якої клієнти ще не бачать
Pull request	Сторінка з пропозицією злити гілку: опис, рев'ю й автоматичні перевірки	Обговорення зміни та її причина
Мердж (злиття)	Об'єднання комітів однієї гілки з іншою, зазвичай із `main`	Зміну прийнято, але не обов'язково викладено
Тег і реліз	Тег — постійна назва одного коміту, наприклад `v2.4.0`; реліз — сторінка на основі тегу з описом змін	Які зміни входять у яку версію

Ще одне слово лежить поза Git: деплой, тобто викладання версії на робочі сервери. Git не записує, чи зміну вже викладено. Одні команди викладають автоматично після кожного мерджу в main, інші — за розкладом або з релізних тегів. Один раз розпитайте розробників, як це влаштовано у вас: від цього залежить кожна відповідь на питання «чи це вже на сайті?».

Як читати сторінку репозиторію

Читайте її згори донизу. GitHub час від часу пересуває кнопки, але самі частини лишаються.

Назва і вкладки. Code показує файли, в Issues живуть баги й задачі, у Pull requests — запропоновані зміни.
Перемикач гілок. Зазвичай у ньому вибрано main. Файли нижче завжди належать вибраній гілці, тож перевірте її, перш ніж робити висновки.
Останній коміт. Автор, повідомлення, короткий хеш і як давно це було. Лічильник комітів поруч відкриває всю історію.
Список файлів. У кожному рядку — повідомлення останнього коміту, який зачепив цей файл чи папку, і час.
README. Вступ до проєкту від самої команди, показаний під списком файлів.

Безкоштовний урок Репозиторій і коміти: як читати сторінку репозиторію проходить кожну частину на репозиторії Котокорму.

Що розповідають повідомлення коміту і diff

Історія комітів — це список повідомлень, найновіші вгорі. Добре повідомлення починається з короткого підсумку у формі вказівки («Fix», «Add», «Raise»; більшість команд пише їх англійською), а якщо причина неочевидна, додає речення про те, навіщо. Порівняйте два повідомлення для тієї самої зміни:

fix
Fix free delivery threshold on checkout, а нижче: «Threshold is 1000 UAH now; checkout still showed 800. (#142)»

Перше змушує відкривати коміт і вгадувати. Друге відповідає на питання просто зі списку. Ви теж на це впливаєте: причина, яку ви вказали в запиті, зрештою опиняється в повідомленні коміту і в pull request.

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

Diff каже, що змінилося, а навіщо — можуть сказати лише повідомлення і pull request. Потренуватися в обох навичках можна в уроці Читаємо історію: повідомлення, diff і blame.

П'ять щоденних питань і де шукати відповідь

Питання	Де дивитися
Чи моє виправлення вже на сайті?	Pull request: чи його змерджено? Далі — реліз або деплой, який був після мерджу
Що змінилося в цьому релізі?	Опис релізу для цієї версії або порівняння двох тегів, яке показує коміти між ними
Хто змінив цей текст і навіщо?	Файл у режимі `Blame`, де біля кожного рядка видно останній коміт, далі pull request цього коміту
Над чим команда працює зараз?	Відкриті pull requests і гілки з нещодавньою активністю
Чому минулого тижня змінилася поведінка?	Історія потрібного файлу або історія комітів `main`, звужена до цих дат

Чого вчити не треба

Командний рядок. Розробники вводять у терміналі git commit чи git log. Усе, що треба прочитати вам, є в браузері.
Rebase, squash і розв'язання конфліктів. Досить знати, що конфлікт (merge conflict) означає: дві гілки по-різному змінили ті самі рядки, і людина має вибрати результат, а це може затримати мердж.
Моделі роботи з гілками в деталях. Вивчіть шлях від гілки до робочого сайту у вашій команді й на цьому зупиніться.
Читання коду. Повідомлення комітів, описи pull requests, тексти й числа в diff закривають більшість питань продакта.

Типові помилки

Вважати, що «змерджено» означає «викладено». Змерджено — це прийнято в main. Чи бачать зміну клієнти, залежить від деплою.

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

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

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

Етикет: blame не для пошуку винних

Blame відповідає на питання «звідки взявся цей рядок?», а не «хто винен?». Розробники постійно запускають його на власному коді.
Питайте з посиланням і про причину: «Яка була логіка в #142?» працює краще, ніж «Навіщо було міняти чекаут?».
Не кидайте чужий коміт у загальний канал із питанням «хто це зламав?». Скасувати невдалу зміну — буденна річ, а відновлювати довіру доводиться значно довше.
У pull request коментуйте те, на чому знаєтеся: тексти, ціни, те, що побачить клієнт. Стиль коду залиште рев'юерам.

Що зробити цього тижня

Отримайте доступ на читання до репозиторію свого продукту.
Запитайте розробника, як змерджена зміна потрапляє на робочий сайт і де видно, що вона туди дійшла.
Візьміть одну зміну, про яку ви нещодавно просили, і простежте її шлях: файл, історія, коміт, pull request, реліз.
Налаштуйте Watch (сповіщення про активність у репозиторії) лише на релізи, щоб знати про кожну нову версію.

Головне

Читати репозиторій безпечно, і командний рядок для цього не потрібен.
Шість термінів закривають більшість розмов: репозиторій, коміт, гілка, pull request, мердж, тег і реліз.
Коміт каже, що і коли змінилося; pull request — навіщо і хто погодив.
Змерджено не означає викладено. З'ясуйте, як викладає зміни ваша команда.
Blame потрібен, щоб знайти причину, а не винного.

FAQ

Чи треба продакт-менеджеру вчити команди Git?

Ні. Команди потрібні тим, хто змінює код на власному комп'ютері. Продакт здебільшого читає файли, історію, pull requests і релізи, а все це є у вебінтерфейсі GitHub.

Чим Git відрізняється від GitHub?

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

Чи можна щось зламати, роззираючись у репозиторії?

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

Як дізнатися, чи змерджена зміна вже на сайті?

Залежить від того, як викладає зміни ваша команда. Якщо кожен мердж у main викладається автоматично, змерджений pull request зазвичай означає, що зміна невдовзі з'явиться на сайті. Якщо команда випускає релізи з тегами, перевірте, чи останній реліз зроблено після мерджу вашої зміни. І наостанок переконайтеся на самому продукті.

Спробуйте на практиці

Безкоштовний урок Навіщо командам історія: контроль версій без страху починає з нуля на репозиторії сайту Котокорму; у ньому є тести й практичне завдання з перевіркою ШІ. З нього починається безкоштовний курс «Git і GitHub для продактів».

Git для продакт-менеджерів: читаємо репозиторій без командного рядка