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

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

Що робить Git

Git розв'язує чотири проблеми, з якими стикається кожна команда, що разом змінює один продукт.

• Історія. Кожен збережений крок, коміт, зберігає і саму зміну, і контекст довкола неї. Навіть за кілька місяців видно, чому змінився поріг доставки чи хто переписав сторінку з цінами.
• Паралельна робота. Розробники працюють в окремих гілках, тож недороблена фіча не ламає версію, якою користуються клієнти.
• Безпечне скасування. Будь-який попередній стан можна відновити. Невдалу зміну скасовують одним новим комітом, і з історії нічого не зникає.
• Спільна робота. У кожного є повна копія проєкту з історією, а Git об'єднує роботу різних людей, коли вона готова.

Git створили 2005 року для ядра Linux, одного з найбільших проєктів з відкритим кодом, і відтоді він став стандартним інструментом для коду. Команди тримають у ньому й усе інше, що живе в текстових файлах: тексти сайту, документацію, налаштування і переклади.

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

Git — це інструмент, який записує історію. Він працює на комп'ютері кожного розробника, власного сайту в нього немає.

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

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

Основи Git: шість термінів простими словами

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

Шлях зміни: від гілки до релізу

Якщо скласти шість термінів разом, вийде маршрут, яким проходить майже кожна зміна:

1. Розробник створює гілку від main, наприклад fix/checkout-text.
2. Зберігає роботу одним чи кількома комітами в цій гілці.
3. Відкриває pull request з описом зміни; колеги роблять рев'ю, запускаються автоматичні перевірки.
4. Pull request мерджать у main.
5. Команда викладає зміну: одразу після мерджу або пізніше, у складі релізу з тегом.

Команди відрізняються здебільшого кроками 1 і 5: скільки живуть гілки і як часто main потрапляє на сайт. Дві поширені моделі роботи з гілками порівнює стаття GitHub flow чи git flow, про команди, які мерджать у main щодня, — trunk-based development, а як читати номери релізів на кшталт v2.4.1, пояснює семантичне версіонування.

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

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

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

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

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

Читайте її згори донизу. 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.

Навіщо Git продакт-менеджеру

Здебільшого щоб відповідати на п'ять щоденних питань, нікого не відволікаючи:

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

Чи треба вчити команди Git

Щоб читати — ні. Ось що можна сміливо пропустити:

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

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

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

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

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

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

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

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

З чого почати цього тижня

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

Головне

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

FAQ

Що таке Git, якщо зовсім просто?

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

Чи складно новачку розібратися в Git?

Читати історію Git нескладно: з шістьма термінами вище новачок за один вечір навчиться простежувати зміну на GitHub. Вносити зміни з командного рядка вчитися довше, але більшості продактів і маркетологів це не знадобиться.

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

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

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

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

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

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

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

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