Free delivery from 800 UAH
+Free delivery from 1000 UAH
``` Отже, у коді текст виправлено, але до сайту він ще не дійшов. За кілька хвилин Sofia відповідає підтримці: «Виправлено, з'явиться на сайті з наступним релізом». А в повідомленні для Daniel уже не «що там із текстом у чекауті?», а «#142 змерджено, але у v2.4.0 його немає. Коли наступний реліз?» Відповідь займає один рядок: у п'ятницю вранці, `v2.4.1`.  ## Як читати сторінку репозиторію Читайте її згори донизу. GitHub час від часу пересуває кнопки, але самі частини лишаються. - **Назва і вкладки.** `Code` показує файли, в `Issues` живуть баги й задачі, у `Pull requests` — запропоновані зміни. - **Перемикач гілок.** Зазвичай у ньому вибрано `main`. Файли нижче завжди належать вибраній гілці, тож перевірте її, перш ніж робити висновки. - **Останній коміт.** Автор, повідомлення, короткий хеш і як давно це було. Лічильник комітів поруч відкриває всю історію. - **Список файлів.** У кожному рядку — повідомлення останнього коміту, який зачепив цей файл чи папку, і час. - **README.** Вступ до проєкту від самої команди, показаний під списком файлів. Безкоштовний урок [Репозиторій і коміти: як читати сторінку репозиторію](/uk/courses/git-for-product/reading-a-repository-page/theory) проходить кожну частину на репозиторії Котокорму. ## Що розповідають повідомлення коміту і 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](/uk/courses/git-for-product/reading-history-diffs-and-blame/theory). ## Навіщо Git продакт-менеджеру Здебільшого щоб відповідати на п'ять щоденних питань, нікого не відволікаючи: | Питання | Де дивитися | | ---------------------------------------- | ------------------------------------------------------------------------------------------------- | | Чи моє виправлення вже на сайті? | Pull request: чи його змерджено? Далі — реліз або деплой, який був після мерджу | | Що змінилося в цьому релізі? | Опис релізу для цієї версії або порівняння двох тегів, яке показує коміти між ними | | Хто змінив цей текст і навіщо? | Файл у режимі `Blame`, де біля кожного рядка видно останній коміт, далі pull request цього коміту | | Над чим команда працює зараз? | Відкриті pull requests і гілки з нещодавньою активністю | | Чому минулого тижня змінилася поведінка? | Історія потрібного файлу або історія комітів `main`, звужена до цих дат | Друге застосування — участь у рев'ю. Код оцінювати не треба, але перевірити тексти, ціни й скриншоти в pull request до мерджу ви можете; що саме коментувати, розповідає стаття [як робити рев'ю pull request](/uk/blog/how-to-review-a-pull-request). ## Чи треба вчити команди Git Щоб читати — ні. Ось що можна сміливо пропустити: - **Командний рядок.** Розробники вводять у терміналі `git commit` чи `git log`. Усе, що треба прочитати вам, є в браузері. А якщо цікаво, що означають команди, які пролітають у чаті команди, загляньте в [шпаргалку з Git](/uk/tools/git-cheat-sheet): там найпоширеніші пояснено простими словами. - **Rebase, squash і розв'язання конфліктів.** Досить знати, що конфлікт (merge conflict) означає: дві гілки по-різному змінили ті самі рядки, і людина має вибрати результат, а це може затримати мердж. - **Моделі роботи з гілками в деталях.** Вивчіть шлях від гілки до робочого сайту у вашій команді й на цьому зупиніться. - **Читання коду.** Повідомлення комітів, описи pull requests, тексти й числа в diff закривають більшість питань продакта. ## Типові помилки **Вважати, що «змерджено» означає «викладено».** Змерджено — це прийнято в `main`. Чи бачать зміну клієнти, залежить від деплою. **Сприймати blame як повну історію.** Blame — це режим перегляду файлу, де біля кожного рядка видно останній коміт, що його зачепив. А той коміт міг лише переформатувати файл. Якщо повідомлення нічого не каже про ваше питання, зазирніть в історії файлу на крок далі. **Міряти продуктивність кількістю комітів.** Кількість комітів чи змінених рядків нічого не каже про цінність зробленого. **Плутати «випустили» і «спрацювало».** Репозиторій каже, що вийшло. Чи змінилася поведінка клієнтів — окреме питання до аналітики, те саме, що стоїть за різницею між [результатом і виходом](/uk/blog/outcome-vs-output). ## Етикет: 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 зазвичай означає, що зміна невдовзі з'явиться на сайті. Якщо команда випускає релізи з тегами, перевірте, чи останній реліз зроблено після мерджу вашої зміни. І наостанок переконайтеся на самому продукті. ## Спробуйте на практиці Безкоштовний урок [Навіщо командам історія: контроль версій без страху](/uk/courses/git-for-product/why-teams-keep-history/theory) починає з нуля на репозиторії сайту Котокорму; у ньому є тести й практичне завдання з перевіркою ШІ. Далі йде урок [Гілки: паралельні версії проєкту](/uk/courses/git-for-product/branches/theory), а весь шлях — це безкоштовний курс [«Git і GitHub для продактів»](/uk/courses/git-for-product). ## Пов’язані уроки - [Навіщо командам історія: контроль версій без страху](https://productovi.com/uk/courses/git-for-product/why-teams-keep-history.md) - [Репозиторій і коміти: як читати сторінку репозиторію](https://productovi.com/uk/courses/git-for-product/reading-a-repository-page.md) - [Читаємо історію: повідомлення, diff і blame](https://productovi.com/uk/courses/git-for-product/reading-history-diffs-and-blame.md) - [Гілки в Git: паралельні версії проєкту](https://productovi.com/uk/courses/git-for-product/branches.md) - [Що таке pull request: анатомія сторінки PR](https://productovi.com/uk/courses/git-for-product/pull-request-anatomy.md)