Removing sensitive data from a repository
Підтверджує й актуалізує поняття уроку: About removing sensitive data from a repository.
2. Git Workflow у PyCharm/IntelliJ → Першоджерело ↗Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Терміни, нюанси та джерела
AGENTS.md instruction chain
Codex поєднує global guidance із project instructions від repository root до current directory. Ближчий AGENTS.md або AGENTS.override.md має вищий пріоритет у своєму scope.
Як налаштувати мультиагентне середовище →Authenticated browser state
Збережені cookies і headers для повторного використання авторизованої browser session. Такий файл може дозволити impersonation test account, тому його не слід комітити навіть у private repository; shared account підходить лише для tests без конфліктних server-side mutations.
Практика курсу на YOY, домашні завдання та формат ПМП →Authentication state є секретом
State-файл може містити cookies і headers, достатні для impersonation. Офіційний guide радить зберігати його поза Git навіть у private repository.
На сторінці може бути різний контент — що робити? →Python 3.13+ автоматично додає ignore-файл у venv
Починаючи з Python 3.13, venv за замовчуванням створює .gitignore всередині environment; це не скасовує потребу перевіряти repository-level ignore policy.
Secret rotation
Якщо credential потрапив у repository history, першою дією є його відкликання або заміна; переписування history саме по собі не робить credential безпечним.
2. Git Workflow у PyCharm/IntelliJ →Entity, DAO, repository та ORM
Entity object відображає таблицю або persistence-модель, DAO інкапсулює низькорівневий доступ до даних, а repository формулює операції мовою домену, наприклад `findUserByEmail`. Межі цих назв різняться між ecosystem, тому важливіше розуміти відповідальність, а не механічно відтворювати всі шари. ORM перетворює об'єкти на relational data та генерує SQL. Він зменшує кількість ручних queries для стандартного CRUD, але не скасовує знання schema, indexes, transactions і joins. Для невеликого test-support helper достатньо вже наявного driver/repository; окремий ORM-шар лише для тестів часто створює дублювання production model.
Commit і push
Commit зберігає перевірений знімок змін у локальному repository. Перед push ще раз перевіряються target branch, commit message і файли в diff. Push передає локальні commits до remote repository. Демонстраційний push у відео завершується SSH permission error, що показує окрему вимогу: SSH URL потребує налаштованого SSH key і доступу до repository.
Доменні межі, кілька застосунків і один стартовий repository
Великий продукт може мати B2C, B2B, back office, tool-sharing або branch-office застосунки зі спільним core. Структуру automation варто повторювати за реальними domain/app boundaries, а common-код піднімати лише тоді, коли він справді спільний. Для нового automation effort рекомендовано починати з одного repository: розділити усталену систему пізніше простіше, ніж одразу координувати кілька репозиторіїв без перевіреної потреби. Один repository також полегшує справжні end-to-end flows через кілька доменів.
Публікація локального проєкту
Для локального проєкту використовується IDE action `Share Project on GitHub`: вказується назва repository та його visibility. Перед першим commit треба переглянути список файлів. `.idea`, логи та інші локальні артефакти не мають випадково потрапити до repository.
Внутрішні registry та контроль залежностей
На enterprise-проєктах доступ до публічних package registries часто обмежують. Дозволені бібліотеки та внутрішні збірки зберігають у корпоративному artifact repository або пропускають через контрольований proxy. Такі сховища дають версіонування, allowlist і сканування вразливостей. Якщо зовнішній пакет не дозволений, команда або погоджує його через встановлений процес, або реалізує мінімально потрібну поведінку самостійно — хоча власний код теж має вартість підтримки й не є автоматично безпечнішим.
Клонування існуючого repository
Якщо repository вже існує на GitHub, GitLab чи Bitbucket, правильний початок — `Git Clone`, а не повторна публікація. З Git hosting копіюється HTTPS або SSH URL, в IDE обирається локальна папка, після чого проєкт клонується. GitHub Desktop може виконати ту саму операцію, але відео демонструє вбудовані IDE-інструменти.
Scope конфігурації та execution image
Repository-level secrets доступні workflow всього репозиторію, тоді як environment secrets можна обмежити конкретним оточенням і його protection rules. Workflow явно посилається на потрібні значення, тому конфігурація стає частиною контракту запуску, але самі секрети не з’являються у YAML. Кожну job варто уявляти як чистий контейнер або машину на базі визначеного image, наприклад `ubuntu-latest`. Наступне практичне відео показує, як на такому runner послідовно виконати checkout, setup, install і tests.
Гілки як знімки стану кожного модуля
[Дивитися з 00:00](https://www.youtube.com/watch?v=FQsfjR_iHoE&t=0s). Для Java- та Python-прикладів підготовлено репозиторії, де окремі гілки відповідають модулям курсу. Перемкнувшись на потрібну гілку, учень бачить реалізацію в тому стані, у якому вона була під час запису заняття. Це дає змогу звірити структуру проєкту, налаштування й код, якщо пояснення у відео було надто швидким або незрозумілим.
Test data й artifacts
Файли зберігають підготовлених users, transactions або результати, які треба передати наступному кроку чи додати до report. Перед записом варто визначити життєвий цикл даних: тимчасовий debug output не повинен назавжди засмічувати repository або CI agent.
Структура навчального репозиторію
Код лежить у `src`, а кожна тема має власний `README.md`, базовий файл і розширений файл. README пояснює терміни та порядок роботи; базовий приклад показує одну конструкцію без зайвої інфраструктури; розширений залишає матеріал для самостійної практики.