Відеобібліотека
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Створіть локальну навчальну branch.
Змініть один безпечний файл і перегляньте git diff.
Stage-ніть лише цей файл та перегляньте git diff --cached перед commit.
Commit містить рівно запланований файл і не містить credentials або локальної конфігурації.
Оберіть один несправний або короткий тест.
Перейменуйте лише його модулі за PEP 8 та оновіть імпорти.
Запустіть Ruff і один цільовий тест, потім перегляньте diff.
Один тест проходить, Ruff не знаходить нових помилок, diff не містить сторонніх змін.
Команди створюють task branch, перевіряють і stage-ять лише потрібний файл, показують staged diff, комітять і публікують branch.
У remote з’являється окрема branch з одним перевіреним commit, готова для Pull Request.
2. Git Workflow у PyCharm/IntelliJ →Pull Request представляє запропоновані зміни з branch і дає команді місце для diff, review, checks та рішення про merge.
2. Git Workflow у PyCharm/IntelliJ →Repository diff є засобом порівняння, а не доказом якості. Перегляньте й зрозумійте зміну, запустіть релевантний check/test і перевірте observable behavior; для authentication, sensitive data, secrets та safety-critical code потрібен сильніший oversight.
Репозиторій як довідник до модулів →Збережіть або закомітьте власні зміни.
Запустіть свій варіант і зафіксуйте конкретну помилку або розбіжність.
Перейдіть на гілку відповідного модуля та знайдіть найменшу суттєву відмінність.
Поверніться до власної гілки, виправте лише підтверджену причину й повторіть запуск.
Назва гілки, команда перевірки, початкова помилка та мінімальний diff виправлення.
Перед кожним commit потрібно відкрити список змінених файлів і переглянути конкретні рядки. Досвід не усуває ризик випадково додати пароль, token, локальну конфігурацію, тимчасовий коментар або сторонню зміну. `.gitignore` зменшує ризик, але не замінює перегляд staged diff. Корисна послідовність: перевірити `git status`, додати лише потрібні файли, переглянути staged diff, створити вузький commit і ще раз перевірити гілку перед push. Коментарі в коді оцінюються за користю; назви функцій, змінних і локаторів мають пояснювати намір без зайвого шуму.
Перед commit треба переглянути кожен changed file і переконатися, що до нього потрапили лише навмисні зміни. Commit message коротко описує зміст. IDE може запустити reformat code, optimize imports і code analysis; ці перевірки допомагають знайти технічні проблеми, але не замінюють ручного diff review.
Під час перегляду diff виявляється пароль, випадково включений у коміт. Якщо коміт ще не відправлено, в IDE можна виконати Undo Commit, замінити значення, знову переглянути diff і створити виправлений коміт. Важливе уточнення: якщо справжній секрет уже потрапив у remote, видалення з поточного файлу або додавання `.gitignore` недостатньо — секрет залишається в історії. Його треба негайно відкликати або змінити, а очищення історії виконувати за погодженим командним процесом.
Для наявного набору Page Objects decorators додаються через project-wide search/replace. Демонстрація показує ризик такого скорочення: regex зачіпає `__init__`, properties та неправильні відступи, після чого зміни доводиться вручну чистити й додавати imports. Після механічної зміни запускаються format check і Ruff. Це обов’язкова межа безпеки для bulk edit: результат пошуку не вважається правильним, доки diff не переглянуто, код не форматується й статичні checks не проходять.
Після локального коміту виконується Push. Перед ним ще раз переглядаються файли та зміни: це остання проста точка, де можна зупинити випадковий коментар, пароль або сторонній файл. У GitHub для нової гілки створюється Pull Request. Заголовок стисло називає зміну, опис пояснює деталі, а вкладка Files changed показує точний diff. Коментарі рев’ю та автоматичні перевірки мають бути опрацьовані до merge.
Після автоматичного рефакторингу переглядається кожен змінений файл. Демонстрація виявляє як нормальні зміни — типи, constants, імпорти — так і небажане видалення файлів та помилку у fixture, яка створила некоректний стан сторінки. AI-агент запускає найменший тест, але сам факт запуску не доводить коректність усієї зміни: треба прочитати failure, перевірити fixture lifecycle і повторити сценарій. Результат оформлюється в окремій гілці та коміті, а не змішується з наступною міграцією інструментів.
Рекомендований цикл: налаштувати безпечний доступ, створити task branch, зробити вузьку зміну, переглянути diff, закомітити, запушити, створити PR і після merge прибрати гілку. Шорткати IDE прискорюють повторювані дії, але не замінюють перевірку змісту. Головне правило безпеки з відео: публікувати код, але не credentials. Якщо є сумнів, перед push потрібно зупинитися й перечитати весь diff.
Однакова конфігурація потрібна, щоб локальний запуск і CI поводилися передбачувано. У проєкті фіксуються мінімальні версії `pytest`, `pytest-playwright`, `pytest-html`, Faker та інших залежностей. Це дає IDE, pytest і CI явні передумови замість неявної залежності від локального середовища автора. На початку також показано Local History і Smart Checkout у PyCharm/IntelliJ. Ці інструменти можуть допомогти повернути локальні зміни або розібрати конфлікт під час перемикання гілки, але не замінюють Git-історію та перевірку diff.
[Дивитися з 02:15](https://www.youtube.com/watch?v=reaHS8_pZbU&t=135s). AI може прискорити механічний refactoring, роботу з CI pipelines, Docker images, reporting, logs і повторюваними змінами. Цінність виникає не від підписки як такої, а від знайденого repeatable workflow: зібрати потрібний context, виконати вузьку задачу, перевірити diff і зберегти лише підтверджений результат. У відео звучить порада приховувати AI use через CLI та локальні ignore rules, якщо client його забороняє. Це ризикована практика: відсутність desktop app не робить передачу даних невидимою для network/security controls і не скасовує contractual restrictions. Без explicit approval не можна передавати proprietary code, secrets, logs або customer data зовнішньому provider. Безпечний шлях — узгоджений tool, дозволений data scope, redaction і локальний/offline workflow там, де це справді відповідає policy.
LLM спочатку отримує вузьку задачу: додати `pytest.mark.parametrize` та згенерувати невалідні значення через Faker. Після запуску результат уточнюється окремими кроками. Такий цикл «малий prompt — diff — запуск — наступне уточнення» краще локалізує помилки, ніж один запит на повний рефакторинг fixtures, даних і тестів одночасно. Пари даних виносяться з decorator у окрему змінну. Це скорочує тіло тесту, дає таблиці предметну назву й дозволяє за потреби перенести test data в окремий модуль. Важливо не генерувати випадкові значення без мети: кожен case має представляти конкретний клас поведінки.