• Продакт-менеджери
• Маркетологи

Git і GitHub для продактів

Більше жодної розгубленості в розмовах із розробниками. Навчіться читати репозиторій, переглядати pull request і простежувати зміну від гілки до релізу просто у вебінтерфейсі GitHub, без терміналу.

Під рукою: Шпаргалка з Git для продактів

Безкоштовно15 уроків~8 год 29 хв навчання

1. Модуль 1

   Git простими словами

   Навіщо командам уся історія проєкту, що таке репозиторій і коміт і як читати цю історію на GitHub: повідомлення комітів, diff і blame.

   1. 1.1Навіщо командам історія: контроль версій без страхуЩо таке контроль версій, чим Git відрізняється від GitHub і чому роззиратися в репозиторії цілком безпечно.~24 хв
   2. 1.2Репозиторій і коміти: як читати сторінку репозиторіюСторінка репозиторію на GitHub згори донизу, що розповідає сторінка окремого коміту і яким має бути добре повідомлення коміту.~26 хв
   3. 1.3Читаємо історію: повідомлення, diff і blameЯк відкрити історію файлу, прочитати diff рядок за рядком і через blame простежити будь-який рядок до його коміту, pull request та issue.~24 хв
   Іспит модуляПройдіть ще 3 уроки, щоб відкрити

2. Модуль 2

   Гілки та мерджі

   Гілки як паралельні версії проєкту, три способи, якими GitHub їх зливає (merge commit, squash, rebase), і що таке конфлікт під час мерджу.

   1. 2.1Гілки: паралельні версії проєктуЩо таке гілка, чому робота йде в короткоживучих гілках поруч із main і як читати гілки на GitHub: перемикач гілок, ahead і behind, застарілі гілки та графи з кількома доріжками.~32 хв
   2. 2.2Злиття: мердж-коміт, squash і rebase на GitHubЩо робить мердж, три варіанти за кнопкою мерджу на GitHub і що кожен лишає в історії, fast-forward простими словами і як перевірити, чи зміна справді в main.~31 хв
   3. 2.3Конфлікти під час мерджу: чому виникають і що робитиЧому дві гілки можуть зіткнутися на тому самому рядку, що тоді показує GitHub, як читати маркери конфлікту й розв'язати простий конфлікт у браузері і чому вибір правильного тексту це продуктове рішення.~34 хв
   Іспит модуляПройдіть ще 3 уроки, щоб відкрити

3. Модуль 3

   Pull requests

   Pull request вкладка за вкладкою, рев'ю очима продакта з коментарями, пропозиціями й схваленням, і що означає кожна іконка та колір GitHub.

   1. 3.1Анатомія pull request: вкладки, опис, перевіркиЧитаємо сторінку pull request згори донизу: базова гілка й гілка змін, чернетка і готовий PR, чотири вкладки, опис, рев'юери й мітки, пов'язані issues, перевірки й блок мерджу.~36 хв
   2. 3.2Рев'ю очима PM: коментарі, пропозиції, approveЩо продакт перевіряє в pull request, а що лишає інженерам, як коментувати рядок, пропонувати точне формулювання, обирати між Comment, Approve і Request changes і писати коментарі, які приємно отримувати.~39 хв
   3. 3.3Іконки й кольори: що означає кожен станЧитаємо pull requests, issues, перевірки, рев'ю, мітки й блок мерджу з першого погляду: що означає кожна іконка й колір GitHub і як розрізняти стани за формою й текстом, а не лише за кольором.~43 хв
   Іспит модуляПройдіть ще 3 уроки, щоб відкрити

4. Модуль 4

   Командні воркфлоу

   GitHub flow з маленькими гілками й швидкими мерджами, git flow з гілками develop, release і hotfix, і як релізи отримують теги, версії та changelog.

   1. 4.1GitHub flow: малі гілки, швидкі мерджіЦикл, у якому працює більшість продуктових команд: гілка від main, pull request, рев'ю й перевірки, мердж, деплой. Чому малі короткоживучі гілки безпечніші, що означають «змерджено» і «викладено», як фіча-флаги дають викласти незавершену роботу прихованою і як читати прогрес фічі зі списку pull requests.~35 хв
   2. 4.2Git flow: гілки develop, release і hotfixМодель гілок, зорієнтована на релізи: довгоживучі main і develop, гілки feature, release і hotfix, теги на main. Коли вона доречна (релізи через магазини застосунків, кілька підтримуваних версій), чому багато вебкоманд перейшли на GitHub flow чи trunk-based development і як упізнати модель за списком гілок.~34 хв
   3. 4.3Релізи й версії: теги, SemVer, changelogЩо таке тег, як читати номер версії на кшталт v1.4.1 (SemVer простими словами), як працюють GitHub Releases і згенеровані нотатки до релізу, як перевірити, чи є виправлення у версії, і чому «змерджено», «випущено» і «доступно всім» можуть бути трьома різними моментами.~38 хв
   Іспит модуляПройдіть ще 3 уроки, щоб відкрити

5. Модуль 5

   GitHub у продуктовій роботі

   Issues, мітки й майлстоуни, дошки проєктів, на яких видно шлях фічі до релізу, і ваша перша зміна в браузері, а також як її відкотити.

   1. 5.1Issues, мітки й майлстоуни; зв'язок PR з issuesЯк перетворити запит в один рядок на issues, з якими команда може працювати: звіти про баги з кроками відтворення, запити на фічі з критеріями приймання, шаблони, мітки, виконавці, sub-issues і майлстоун із дедлайном. А ще як ключові слова закриття й згадки пов'язують pull requests з issues і що кожен стан issue каже продакту.~39 хв
   2. 5.2Дошки проєктів: як провести фічу до релізуGitHub Projects для продакта: макети дошки, таблиці й roadmap, поле статусу й власні поля, вбудовані воркфлоу, що рухають картки, і як провести фічу від issue через pull request, мердж і реліз до фіча-флагу. Чому «Done» на дошці не завжди означає, що клієнти вже можуть цим користуватися, і що показати CEO.~36 хв
   3. 5.3Перша зміна в браузері і як її скасуватиНевелика зміна повністю у вебінтерфейсі GitHub: знайти файл, відредагувати, закомітити в нову гілку, бо main захищена, відкрити pull request, пройти перевірки й рев'ю, змерджити й викласти. А потім скасувати змерджену зміну кнопкою Revert, розібратися, коли робити revert, а коли виправляти вперед, і що продакту варто й не варто редагувати самостійно.~38 хв
   Іспит модуляПройдіть ще 3 уроки, щоб відкрити