Відеобібліотека
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Команди створюють task branch, перевіряють і stage-ять лише потрібний файл, показують staged diff, комітять і публікують branch.
У remote з’являється окрема branch з одним перевіреним commit, готова для Pull Request.
2. Git Workflow у PyCharm/IntelliJ →В окремому навчальному repository додайте правила для .venv/, .env і test results.
Перевірте кожен path через git check-ignore -v.
Задайте local user.name і user.email, потім перевірте їх через git config --list --show-origin.
Команди перевірки та staged diff, у якому немає .env і generated artifacts.
Чинна Git documentation прямо зазначає: files already tracked by Git are not affected; їх потрібно окремо вилучити з index, перш ніж ignore pattern запобігатиме повторному додаванню.
3. Селектори та пошук елементів →Створіть локальну навчальну branch.
Змініть один безпечний файл і перегляньте git diff.
Stage-ніть лише цей файл та перегляньте git diff --cached перед commit.
Commit містить рівно запланований файл і не містить credentials або локальної конфігурації.
Створіть auth state локально й переконайтеся, що файл заігнорований Git.
Додайте feature cookie через context.
Поставте page.pause() і перевірте cookie в DevTools Application перед assertion.
Тест повторно використовує login, cookie видно на правильному origin, state-файл не відстежується Git.
Окрема лінія стану репозиторію. git switch <branch> оновлює working tree та index відповідно до вибраної гілки.
Кожен commit містить ім'я та email автора. Якщо на машині є персональний GitHub, корпоративний акаунт і окремий клієнтський профіль, один глобальний config може створити неправильну історію авторства. Тому для робочих репозиторіїв корисно задавати `user.name` і `user.email` локально. Практичні команди: `git config --list --show-origin` показує активні значення та їх джерела; `git config user.name` і `git config user.email` читають поточну ефективну ідентичність; `git config --local user.name "Name"` та `git config --local user.email "email@example.com"` задають її лише для поточного репозиторію. Для груп каталогів Git також підтримує умовні include-правила, наприклад окремий профіль для всіх репозиторіїв певної компанії.
`.gitignore` описує файли й каталоги, які Git не має додавати до індексу як нові untracked-зміни. Зазвичай проєктний файл лежить у корені репозиторію. IDE також може мати власні налаштування або ignore-файли, але вони не замінюють правила Git, які мають однаково працювати для всіх учасників і в CI. У PyCharm, IntelliJ IDEA, WebStorm або VS Code плагін для ignore-файлів може дати шаблони та зрозуміле підсвічування. Навіть після `git add .` Git пропустить нові файли, які відповідають правилам `.gitignore`. Водночас правило не прибирає файл, якщо Git уже почав його відстежувати: такий файл треба окремо вилучити з індексу без видалення локальної копії.
У демонстрації виправляється помилка з назвою `.ignore`: для Git потрібен саме `.gitignore`. Схожий суфікс використовують й інші інструменти у власних файлах, наприклад `.cursorignore`, але кожен із них має окреме призначення. Рекомендований стартовий workflow: ініціалізувати Git-репозиторій, створити `.gitignore`, одразу записати відомі локальні каталоги на кшталт `.idea/`, `.venv/` і результатів тестів, а вже потім індексувати потрібні вихідні файли. IDE може запитувати, чи автоматично додавати новостворені файли до Git; це зручно, якщо ignore-правила вже захищають локальні артефакти.
Якщо repository вже існує на GitHub, GitLab чи Bitbucket, правильний початок — `Git Clone`, а не повторна публікація. З Git hosting копіюється HTTPS або SSH URL, в IDE обирається локальна папка, після чого проєкт клонується. GitHub Desktop може виконати ту саму операцію, але відео демонструє вбудовані IDE-інструменти.
Початкова проблема — файли названо з великої літери, хоча Python-конвенція вимагає `snake_case` і нижнього регістру для модулів. Просте ручне перейменування не гарантує, що динамічні імпорти та всі usages буде знайдено, тому спочатку потрібен аналіз повного графа використання. AI-агент отримує вузьку технічну задачу: знайти невідповідні PEP 8 назви, скласти план і виконати перейменування разом з оновленням імпортів. Для збереження Git-історії файлів використовується `git mv`. Після окремої завершеної задачі варто починати нову AI-сесію, щоб старий контекст не впливав на наступний етап.
`Commit` зберігає зміни лише локально; `Commit and Push` одразу відправляє їх у remote. Часті push можуть запускати CI, тому слід розуміти, які jobs і витрати прив’язані до гілки. Водночас довго тримати єдину копію роботи лише локально теж ризиковано — ритм push узгоджують з командою. Git може попросити `user.name` і `user.email`. Email має бути пов’язаний із потрібним GitHub/GitLab/Bitbucket-акаунтом або бути відповідним `noreply` email. Для робочих і особистих репозиторіїв автор радить локальні налаштування репозиторію замість одного `--global` identity.
SSH використовує пару ключів. Приватний ключ залишається лише на довіреному комп’ютері й не публікується. Публічний ключ призначений для передавання сервісу на кшталт GitHub: сервер пов’язує його з акаунтом і перевіряє, що клієнт володіє відповідним приватним ключем. Якщо локальний проєкт уже ініціалізовано як Git-репозиторій, PyCharm/IntelliJ може опублікувати його через Share Project on GitHub. Перед цим варто налаштувати автентифікацію та перевірити, під яким акаунтом працює IDE.
Перед комітом створюється окрема гілка. До diff входять код завантаження конфігурації, `.gitignore` і залежність, але не локальний `.env`. Перед push ще раз перевіряється, що email і пароль не відстежуються. Це важлива межа: `.env` захищає локальні секрети від випадкового Git tracking, але не є менеджером секретів для CI. У CI значення мають надходити з захищених variables/secrets платформи.
Віртуальне середовище `.venv` не потрібно комітити. Налаштування `.idea` в уроці також додаються до `.gitignore`, хоча частина спільних JetBrains-конфігурацій може бути корисною для команди — це слід вирішити явно. Кольори в Project view показують стан файлів відносно Git. Якщо файл уже потрапив до індексу, просте додавання правила в `.gitignore` не прибере його автоматично: спочатку його потрібно вилучити з індексу, не видаляючи потрібний локальний вміст.
Перед першим комітом Git запитує ім’я та email автора. Автор радить не встановлювати ці значення глобально, якщо для особистих і робочих репозиторіїв використовуються різні облікові дані. Після локального коміту проєкт можна опублікувати через Share Project on GitHub, авторизувати PyCharm і створити remote-репозиторій. Коміт і публікація — різні дії: зелений статус файлів показує локальну індексацію/зміни, а наявність remote і push потрібно перевіряти окремо. Підсумкова стратегія локаторів: обирати читабельні атрибути, які команда може контролювати; домовлятися про них з розробниками; accessibility-, CSS- та XPath-підходи використовувати відповідно до реальної розмітки, а не як догму.