Відеобібліотека
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Створіть локальну навчальну branch.
Змініть один безпечний файл і перегляньте git diff.
Stage-ніть лише цей файл та перегляньте git diff --cached перед commit.
Commit містить рівно запланований файл і не містить credentials або локальної конфігурації.
У відео згадано суперечливі рекомендації щодо commit lock-файлів, після чого автор схиляється до commit uv.lock.
Поточна документація uv прямо вказує, що uv.lock слід зберігати у version control для узгоджених і відтворюваних установок.
Команди створюють task branch, перевіряють і stage-ять лише потрібний файл, показують staged diff, комітять і публікують branch.
У remote з’являється окрема branch з одним перевіреним commit, готова для Pull Request.
2. Git Workflow у PyCharm/IntelliJ →Проміжний стан підготовленого snapshot, до якого git add записує зміни перед створенням commit; already tracked files не перестають відстежуватися через нове правило .gitignore.
Урок радить узгоджувати версії Allure CLI та Python integration.
allure-pytest package metadata pin-ить ту саму версію allure-python-commons і вимагає pytest>=4.5.0, але не оголошує dependency або version matrix для Allure CLI. Сумісність генератора й adapter треба доводити pipeline run.
Package metadata commit d420cff86a6bb4a9b42cd16164cd5828b84a24ef перевірено 2026-07-31.
4. Allure репорт, основи та інтеграція в CI →Фіксує immutable checkout revision, використану в code-001.
2. Практика та написання пайплану CI/CD → Першоджерело ↗Перед commit треба переглянути кожен changed file і переконатися, що до нього потрапили лише навмисні зміни. Commit message коротко описує зміст. IDE може запустити reformat code, optimize imports і code analysis; ці перевірки допомагають знайти технічні проблеми, але не замінюють ручного diff review.
У діалозі Commit перший рядок повідомлення має стисло пояснювати завершену зміну. Нижче можна додати деталі, необхідні для майбутнього пошуку й code review. Ідентифікатор задачі в повідомленні або назві гілки допомагає простежити контекст. Перед комітом IDE може виконати Reformat Code та Optimize Imports. Ці операції потрібно переглянути так само, як ручні зміни: автоматичне форматування не є гарантією коректності.
Перед кожним commit потрібно відкрити список змінених файлів і переглянути конкретні рядки. Досвід не усуває ризик випадково додати пароль, token, локальну конфігурацію, тимчасовий коментар або сторонню зміну. `.gitignore` зменшує ризик, але не замінює перегляд staged diff. Корисна послідовність: перевірити `git status`, додати лише потрібні файли, переглянути staged diff, створити вузький commit і ще раз перевірити гілку перед push. Коментарі в коді оцінюються за користю; назви функцій, змінних і локаторів мають пояснювати намір без зайвого шуму.
Commit зберігає перевірений знімок змін у локальному repository. Перед push ще раз перевіряються target branch, commit message і файли в diff. Push передає локальні commits до remote repository. Демонстраційний push у відео завершується SSH permission error, що показує окрему вимогу: SSH URL потребує налаштованого SSH key і доступу до repository.
`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` недостатньо — секрет залишається в історії. Його треба негайно відкликати або змінити, а очищення історії виконувати за погодженим командним процесом.
Після міграції тест запускається через команду `uv run ...` з консолі, бо це ближче до майбутнього CI-запуску, ніж Run Configuration IDE. Треба перевірити, що виконався потрібний тест і що очікуване падіння справді належить тестовій логіці, а не відсутній залежності чи неправильному шляху. Фінальний крок — створити короткий `README` з мінімальною версією Python, установкою, командами запуску, структурою та правилами внесення змін. Commit message перевіряється вручну: він має називати реальну міграцію на `uv` і підключення Ruff, а не перелічувати випадкові деталі diff.
Для локального проєкту використовується IDE action `Share Project on GitHub`: вказується назва repository та його visibility. Перед першим commit треба переглянути список файлів. `.idea`, логи та інші локальні артефакти не мають випадково потрапити до repository.
Fix комітиться й повторно запускається в pull request. Linter і smoke можуть стартувати паралельно, щоб базова функціональна перевірка не чекала на завершення статичного аналізу; точна залежність між jobs визначається вимогами проєкту. Після оновлення п’ять smoke tests проходять. Практичний цикл завершено повним ланцюжком: CI failure → artifact → локальний Trace Viewer → вузька зміна → повторний зелений smoke run.
[Дивитися з 10:30](https://www.youtube.com/watch?v=viR9Rnmxse4&t=630s). Щотижня очікується один або кілька нових tests. Перша домашня робота публікується як repository link; наступні — в окремих branches і pull requests порівняно з `main`. Це дає reviewer-у точний diff конкретного модуля, а учневі — невеликий, але реальний portfolio artifact. Якщо PR уже merged, треба чітко вказати commit або зміни, які відповідають домашній роботі.