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

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

- Джерело: https://productovi.com/uk/courses/git-for-product
- Безкоштовно, читати можна без реєстрації.

## Модулі

### Модуль 1. Git простими словами

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

- [Навіщо командам історія: контроль версій без страху](https://productovi.com/uk/courses/git-for-product/why-teams-keep-history.md): Що таке система контролю версій, чим Git відрізняється від GitHub і чому роззиратися в репозиторії цілком безпечно.
- [Репозиторій і коміти: як читати сторінку репозиторію](https://productovi.com/uk/courses/git-for-product/reading-a-repository-page.md): Що таке репозиторій на GitHub, його сторінка згори донизу, що розповідає окремий коміт і яким має бути добре повідомлення коміту.
- [Читаємо історію: повідомлення, diff і blame](https://productovi.com/uk/courses/git-for-product/reading-history-diffs-and-blame.md): Як відкрити історію файлу, прочитати diff рядок за рядком і через blame простежити будь-який рядок до його коміту, pull request та issue.

### Модуль 2. Гілки та мерджі

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

- [Гілки в Git: паралельні версії проєкту](https://productovi.com/uk/courses/git-for-product/branches.md): Що таке гілка в Git (git branch), чому робота йде в короткоживучих гілках поруч із main і як читати гілки на GitHub: перемикач гілок, ahead і behind, застарілі гілки, правила назв і графи з кількома доріжками.
- [Злиття (git merge): мердж-коміт, squash і rebase на GitHub](https://productovi.com/uk/courses/git-for-product/merging.md): Що робить мердж (git merge), три варіанти за кнопкою мерджу на GitHub (merge commit, squash and merge, rebase and merge) і що кожен лишає в історії, fast-forward простими словами і як перевірити, чи зміна справді в main.
- [Конфлікти злиття (merge conflict): чому виникають і що робити](https://productovi.com/uk/courses/git-for-product/merge-conflicts.md): Що таке merge conflict на GitHub і чому дві гілки можуть зіткнутися на тому самому рядку, що означає «This branch has conflicts that must be resolved», як читати маркери конфлікту й розв'язати простий конфлікт у браузері і чому вибір правильного тексту це продуктове рішення.

### Модуль 3. Pull requests

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

- [Що таке pull request: анатомія сторінки PR](https://productovi.com/uk/courses/git-for-product/pull-request-anatomy.md): Що таке pull request, згори донизу: базова гілка й гілка змін, чернетка і готовий PR, чотири вкладки, опис і шаблон pull request, рев'юери й мітки, пов'язані issues, перевірки й блок мерджу.
- [Рев'ю pull request очима PM: коментарі, пропозиції, approve](https://productovi.com/uk/courses/git-for-product/reviewing-as-a-pm.md): Що продакт перевіряє в pull request, а що лишає інженерам, як коментувати рядок, пропонувати зміни з точним формулюванням, вирішувати, коли схвалити pull request, а коли попросити змін, і писати коментарі до рев'ю, які приємно отримувати.
- [Іконки, кольори й перевірки: що означає кожен стан GitHub](https://productovi.com/uk/courses/git-for-product/icons-and-colours.md): Читаємо статуси pull request, issues, GitHub checks, рев'ю, мітки й блок мерджу з першого погляду: що означає кожна іконка й колір, чим змерджений PR відрізняється від закритого і як розрізняти стани за формою й текстом, а не лише за кольором.

### Модуль 4. Командні воркфлоу

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

- [GitHub flow: малі гілки, швидкі мерджі](https://productovi.com/uk/courses/git-for-product/github-flow.md): Цикл, у якому працює більшість продуктових команд: гілка від main, pull request, рев'ю й перевірки, мердж, деплой. Чому малі короткоживучі гілки безпечніші, що означають «змерджено» і «викладено», як фіча-флаги дають викласти незавершену роботу прихованою і як читати прогрес фічі зі списку pull requests.
- [Git flow: гілки develop, release і hotfix](https://productovi.com/uk/courses/git-for-product/git-flow.md): Модель гілок, зорієнтована на релізи: довгоживучі main і develop, гілки feature, release-гілка для кожної версії, гілки hotfix і теги на main. Коли вона доречна (релізи через магазини застосунків, кілька підтримуваних версій), чому багато вебкоманд перейшли на GitHub flow чи trunk-based development і як упізнати модель за списком гілок.
- [Релізи на GitHub і версії: теги, SemVer, changelog](https://productovi.com/uk/courses/git-for-product/releases-and-versions.md): Що таке тег Git, як читати номер версії на кшталт v1.4.1 (SemVer простими словами), як працюють релізи на GitHub і згенеровані release notes, чим вони відрізняються від changelog, як перевірити, чи є виправлення у версії, і чому «змерджено», «випущено» і «доступно всім» можуть бути трьома різними моментами.

### Модуль 5. GitHub у продуктовій роботі

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

- [Баг-репорт і GitHub issues: шаблони, мітки й майлстоуни](https://productovi.com/uk/courses/git-for-product/issues-labels-milestones.md): Як перетворити запит в один рядок на issues, з якими команда може працювати: як написати баг-репорт із кроками відтворення, запити на фічі з критеріями приймання, шаблон issue на GitHub, мітки, виконавці, sub-issues і майлстоун із дедлайном. А ще як ключові слова закриття й згадки пов'язують pull requests з issues і що кожен стан issue каже продакту.
- [GitHub Projects: дошка проєкту від issue до релізу](https://productovi.com/uk/courses/git-for-product/project-boards.md): GitHub Projects для продакта: макети канбан-дошки, таблиці й roadmap, поле статусу й власні поля, вбудовані воркфлоу, що рухають картки, і як провести фічу від issue через pull request, мердж і реліз до фіча-флагу. Чому «Done» на дошці не завжди означає, що клієнти вже можуть цим користуватися, і що показати CEO.
- [Перша зміна в браузері і як її відкотити через revert](https://productovi.com/uk/courses/git-for-product/first-change-in-the-browser.md): Невелика зміна повністю у вебінтерфейсі GitHub: знайти файл, відредагувати його у вебредакторі GitHub, закомітити в нову гілку, бо main захищена, відкрити pull request, пройти перевірки й рев'ю, змерджити й викласти. А потім зробити git revert змердженої зміни кнопкою Revert на GitHub, розібратися, коли відкочувати, а коли виправляти вперед, і що продакту варто й не варто редагувати самостійно.