2. Git Workflow у PyCharm/IntelliJ

SSH використовує пару ключів. Приватний ключ залишається лише на довіреному комп’ютері й не публікується. Публічний ключ призначений для передавання сервісу на кшталт GitHub: сервер пов’язує його з акаунтом і перевіряє, що клієнт володіє відповідним приватним ключем.

Якщо локальний проєкт уже ініціалізовано як Git-репозиторій, PyCharm/IntelliJ може опублікувати його через Share Project on GitHub. Перед цим варто налаштувати автентифікацію та перевірити, під яким акаунтом працює IDE.

Показано генерацію ключа командою ssh-keygen з email-коментарем, вибір шляху збереження та введення passphrase. Символи passphrase в терміналі не відображаються — це нормальна поведінка.

Публічну частину додають у GitHub Settings → SSH and GPG keys. Приватну частину не копіюють у GitHub, чати або репозиторій. Додатково рекомендується ввімкнути двофакторну автентифікацію. Після зміни налаштувань автентифікації IDE може знадобитися перезапуск.

Перед комітом створюється нова гілка. Для командної роботи назва починається з ідентифікатора задачі з Jira, Linear або іншої системи, а далі містить короткий опис. Це пов’язує код з конкретною роботою й спрощує пошук історії.

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

git switch -c TASK-123-short-description
git diff --check
git add path/to/changed_file.py
git diff --cached
git commit -m "TASK-123 Add project search test"
git push -u origin HEAD

У діалозі Commit перший рядок повідомлення має стисло пояснювати завершену зміну. Нижче можна додати деталі, необхідні для майбутнього пошуку й code review. Ідентифікатор задачі в повідомленні або назві гілки допомагає простежити контекст.

Перед комітом IDE може виконати Reformat Code та Optimize Imports. Ці операції потрібно переглянути так само, як ручні зміни: автоматичне форматування не є гарантією коректності.

Commit зберігає зміни лише локально; Commit and Push одразу відправляє їх у remote. Часті push можуть запускати CI, тому слід розуміти, які jobs і витрати прив’язані до гілки. Водночас довго тримати єдину копію роботи лише локально теж ризиковано — ритм push узгоджують з командою.

Git може попросити user.name і user.email. Email має бути пов’язаний із потрібним GitHub/GitLab/Bitbucket-акаунтом або бути відповідним noreply email. Для робочих і особистих репозиторіїв автор радить локальні налаштування репозиторію замість одного --global identity.

Під час перегляду diff виявляється пароль, випадково включений у коміт. Якщо коміт ще не відправлено, в IDE можна виконати Undo Commit, замінити значення, знову переглянути diff і створити виправлений коміт.

Важливе уточнення: якщо справжній секрет уже потрапив у remote, видалення з поточного файлу або додавання .gitignore недостатньо — секрет залишається в історії. Його треба негайно відкликати або змінити, а очищення історії виконувати за погодженим командним процесом.

Після локального коміту виконується Push. Перед ним ще раз переглядаються файли та зміни: це остання проста точка, де можна зупинити випадковий коментар, пароль або сторонній файл.

У GitHub для нової гілки створюється Pull Request. Заголовок стисло називає зміну, опис пояснює деталі, а вкладка Files changed показує точний diff. Коментарі рев’ю та автоматичні перевірки мають бути опрацьовані до merge.

Якщо задачу треба відкласти, достатньо повернутися на main; її коміти залишаються у власній гілці. Після завершення та схвалення зміни гілка зливається відповідно до правил репозиторію.

У сольній демонстрації показано локальний merge у main і подальший push. У командному проєкті джерелом правил є захищена гілка та PR workflow: не слід обходити review локальним merge. Після успішного merge локальну й remote-гілку можна видалити — коміти залишаються в історії.

Рекомендований цикл: налаштувати безпечний доступ, створити task branch, зробити вузьку зміну, переглянути diff, закомітити, запушити, створити PR і після merge прибрати гілку. Шорткати IDE прискорюють повторювані дії, але не замінюють перевірку змісту.

Головне правило безпеки з відео: публікувати код, але не credentials. Якщо є сумнів, перед push потрібно зупинитися й перечитати весь diff.