Git index
Проміжний стан підготовленого snapshot, до якого git add записує зміни перед створенням commit; already tracked files не перестають відстежуватися через нове правило .gitignore.
Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Терміни, нюанси та джерела
Python 3.13+ автоматично додає ignore-файл у venv
Починаючи з Python 3.13, venv за замовчуванням створює .gitignore всередині environment; це не скасовує потребу перевіряти repository-level ignore policy.
Перевірити ignore rule без commit
Створює тимчасовий repository й перевіряє, що .env відповідає правилу .gitignore.
Команда завершується з exit code 0; .env розпізнано як ignored.
.gitignore
Versioned список patterns для intentionally untracked files; він не впливає на files, які Git уже відстежує.
3. Селектори та пошук елементів →.gitignore
Version-controlled файл patterns для intentionally untracked files, які мають ігноруватися в певній частині working tree.
Гітігнор та як працювати з гітом та не помилитись →gitignore Documentation
Фіксує precedence, pattern format і поведінку already tracked files.
Гітігнор та як працювати з гітом та не помилитись → Першоджерело ↗Що робить `.gitignore`
`.gitignore` описує файли й каталоги, які Git не має додавати до індексу як нові untracked-зміни. Зазвичай проєктний файл лежить у корені репозиторію. IDE також може мати власні налаштування або ignore-файли, але вони не замінюють правила Git, які мають однаково працювати для всіх учасників і в CI. У PyCharm, IntelliJ IDEA, WebStorm або VS Code плагін для ignore-файлів може дати шаблони та зрозуміле підсвічування. Навіть після `git add .` Git пропустить нові файли, які відповідають правилам `.gitignore`. Водночас правило не прибирає файл, якщо Git уже почав його відстежувати: такий файл треба окремо вилучити з індексу без видалення локальної копії.
`.env` як локальна конфігурація
Автотести розглядаються як застосунок, якому потрібна конфігурація: базові URL, email, пароль та інші параметри запуску. У корені проєкту створюється `.env`, а імена незмінних конфігурацій записуються в `UPPER_SNAKE_CASE`, наприклад `BASE_URL`, `EMAIL`, `PASSWORD`. `.env` і `.venv` додаються до `.gitignore`. Сірий файл в IDE означає, що Git його не відстежує. Важливе уточнення: `.gitignore` діє лише на невідстежувані файли. Якщо `.env` уже був закомічений, його треба прибрати з індексу; якщо секрет уже опублікований — також відкликати або змінити сам секрет.
Підготовка файлів до коміту
Віртуальне середовище `.venv` не потрібно комітити. Налаштування `.idea` в уроці також додаються до `.gitignore`, хоча частина спільних JetBrains-конфігурацій може бути корисною для команди — це слід вирішити явно. Кольори в Project view показують стан файлів відносно Git. Якщо файл уже потрапив до індексу, просте додавання правила в `.gitignore` не прибере його автоматично: спочатку його потрібно вилучити з індексу, не видаляючи потрібний локальний вміст.
Що не можна комітити
До Git додаються source code, Gradle Wrapper і потрібні configuration files. Не комітяться `.gradle`, `build`, `out`, локальна `.idea`, Maven build output та файли з environment variables чи secrets. Виняток для частини `.idea` може бути свідомим командним рішенням, наприклад для спільного code style. `.gitignore` має явно захищати repository від згенерованого сміття та приватних даних.
Старт нового репозиторію без зайвих файлів
У демонстрації виправляється помилка з назвою `.ignore`: для Git потрібен саме `.gitignore`. Схожий суфікс використовують й інші інструменти у власних файлах, наприклад `.cursorignore`, але кожен із них має окреме призначення. Рекомендований стартовий workflow: ініціалізувати Git-репозиторій, створити `.gitignore`, одразу записати відомі локальні каталоги на кшталт `.idea/`, `.venv/` і результатів тестів, а вже потім індексувати потрібні вихідні файли. IDE може запитувати, чи автоматично додавати новостворені файли до Git; це зручно, якщо ignore-правила вже захищають локальні артефакти.
Кілька середовищ і поступова еволюція конфігурації
Для dev, staging, UAT та інших середовищ можуть існувати окремі локальні файли, і кожен із них має бути проігнорований. Якщо файл випадково додали до індексу, простого нового правила в `.gitignore` недостатньо: треба забрати його зі staged/tracked стану й тільки тоді перевірити ignore. Середовище не завжди визначається окремим доменом. Маршрутизація може залежати від path, cookie, custom header або feature flag; у production подібний механізм використовується для canary release. У тестах ці параметри мають бути явною конфігурацією, а не розкиданими константами. Ланцюжок розвитку у відео: hardcode → `.env` → структурований config → централізований config server. Перехід потрібен лише тоді, коли попередній варіант уже створює вимірювану незручність або ризик.
Консольний запуск, HTML report і Git hygiene
Запуск простої команди `pytest` у терміналі відтворює спосіб, у який suite згодом стартуватиме на CI. Така перевірка важлива: запуск через IDE може мати інший working directory, environment або власні параметри. `pytest-html` створює початковий звіт зі статусами тестів і доступними логами. Його достатньо для першої діагностики на CI: знайти failed test, переглянути повідомлення, а потім локально відтворити проблему з trace. Звіт не замінює повну observability, але дає мінімальний переносний артефакт. Каталоги з HTML-звітами, screenshots і traces додаються до `.gitignore`. Це результати конкретного запуску, а не вихідний код; їх треба публікувати як CI artifacts, а не комітити в репозиторій.
Де й у якому форматі зберігати state
Playwright записує state як JSON із cookies та origins/local storage. Cookie містить `name`, `value`, `domain`, `path`, expiration, `httpOnly`, `secure` та інші параметри; новий context отримує цей файл через `storage_state`. Файл не можна комітити: він може містити чинну сесію та дані внутрішньої інфраструктури. У прикладі state лежить у вже заігнореній `test-results`; окрема директорія також прийнятна, якщо вона гарантовано додана до `.gitignore`.
Публікація локального проєкту
Для локального проєкту використовується IDE action `Share Project on GitHub`: вказується назва repository та його visibility. Перед першим commit треба переглянути список файлів. `.idea`, логи та інші локальні артефакти не мають випадково потрапити до repository.
Структура папок і створення проєкту
Перед створенням проєкту варто перевірити його фізичний шлях. Особисті та робочі репозиторії краще розділяти: наприклад, тримати open-source й особисті проєкти в окремій папці, а робочі — у папці конкретної компанії. Це зменшує плутанину між різними обліковими записами, репозиторіями та середовищами. Навчальний проєкт присвячений Testomat.io — системі керування тестами. У ньому далі автоматизуватимуться операції зі створення проєктів, папок і тест-кейсів. Під час створення можна залишити стартовий скрипт. Нові файли проєкту варто додавати до Git, якщо вони справді є частиною коду; зайве згодом можна видалити або додати до `.gitignore`.