Відеобібліотека
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Для вже опублікованої feature branch поточна Git documentation надає --force-with-lease як захисний варіант. Він не робить history rewrite безпечним автоматично: branch має бути персональною, а переписування — дозволеним командними правилами.
Підтверджує й актуалізує поняття уроку: --force-with-lease.
2.1. відео, енв файл → Першоджерело ↗Команди створюють task branch, перевіряють і stage-ять лише потрібний файл, показують staged diff, комітять і публікують branch.
У remote з’являється окрема branch з одним перевіреним commit, готова для Pull Request.
2. Git Workflow у PyCharm/IntelliJ →`Commit` зберігає зміни лише локально; `Commit and Push` одразу відправляє їх у remote. Часті push можуть запускати CI, тому слід розуміти, які jobs і витрати прив’язані до гілки. Водночас довго тримати єдину копію роботи лише локально теж ризиковано — ритм push узгоджують з командою. Git може попросити `user.name` і `user.email`. Email має бути пов’язаний із потрібним GitHub/GitLab/Bitbucket-акаунтом або бути відповідним `noreply` email. Для робочих і особистих репозиторіїв автор радить локальні налаштування репозиторію замість одного `--global` identity.
Commit зберігає перевірений знімок змін у локальному repository. Перед push ще раз перевіряються target branch, commit message і файли в diff. Push передає локальні commits до remote repository. Демонстраційний push у відео завершується SSH permission error, що показує окрему вимогу: SSH URL потребує налаштованого SSH key і доступу до repository.
Amend замінює останній коміт новою версією, що дозволяє додати забутий файл без окремого шумового коміту. Якщо попередній коміт уже запушено, його hash змінився, тому звичайний push відхиляється як non-fast-forward. У відео показано force-push у власну feature-гілку й окремо застережено не робити цього в `main`. Практичне уточнення: безпечніший варіант — `--force-with-lease`, і лише коли правила репозиторію дозволяють переписування гілки та ніхто інший не базує на ній роботу. Якщо це не погоджено, простіше додати новий виправний коміт.
Перед кожним commit потрібно відкрити список змінених файлів і переглянути конкретні рядки. Досвід не усуває ризик випадково додати пароль, token, локальну конфігурацію, тимчасовий коментар або сторонню зміну. `.gitignore` зменшує ризик, але не замінює перегляд staged diff. Корисна послідовність: перевірити `git status`, додати лише потрібні файли, переглянути staged diff, створити вузький commit і ще раз перевірити гілку перед push. Коментарі в коді оцінюються за користю; назви функцій, змінних і локаторів мають пояснювати намір без зайвого шуму.
Після локального коміту виконується Push. Перед ним ще раз переглядаються файли та зміни: це остання проста точка, де можна зупинити випадковий коментар, пароль або сторонній файл. У GitHub для нової гілки створюється Pull Request. Заголовок стисло називає зміну, опис пояснює деталі, а вкладка Files changed показує точний diff. Коментарі рев’ю та автоматичні перевірки мають бути опрацьовані до merge.
Перед комітом створюється окрема гілка. До diff входять код завантаження конфігурації, `.gitignore` і залежність, але не локальний `.env`. Перед push ще раз перевіряється, що email і пароль не відстежуються. Це важлива межа: `.env` захищає локальні секрети від випадкового Git tracking, але не є менеджером секретів для CI. У CI значення мають надходити з захищених variables/secrets платформи.
Перед комітом перевіряється, що Faker має зафіксовану версію в `requirements.txt`, а всі тести проходять після переходу на dataclass і fixture. Повідомлення коміту описує обидві зміни: типізовану конфігурацію та генерацію тестових даних. Підсумковий стан: конфігурація незмінна й має явний тип, негативний сценарій використовує згенерований пароль, а логін виконується fixture лише там, де потрібен. Це зменшує дублювання без передчасного переходу до складнішої архітектури.
Якщо задачу треба відкласти, достатньо повернутися на `main`; її коміти залишаються у власній гілці. Після завершення та схвалення зміни гілка зливається відповідно до правил репозиторію. У сольній демонстрації показано локальний merge у `main` і подальший push. У командному проєкті джерелом правил є захищена гілка та PR workflow: не слід обходити review локальним merge. Після успішного merge локальну й remote-гілку можна видалити — коміти залишаються в історії.
Рекомендований цикл: налаштувати безпечний доступ, створити task branch, зробити вузьку зміну, переглянути diff, закомітити, запушити, створити PR і після merge прибрати гілку. Шорткати IDE прискорюють повторювані дії, але не замінюють перевірку змісту. Головне правило безпеки з відео: публікувати код, але не credentials. Якщо є сумнів, перед push потрібно зупинитися й перечитати весь diff.
Спроба вивести URL через `run` у неправильному місці YAML ламає workflow schema, і GitHub відхиляє конфігурацію ще до тестів. Команду переносять усередину валідного step. IDE plugin і GitHub validation допомагають ловити такі структурні помилки до або одразу після push. Фінальний мінімальний ланцюжок: pytest створює `allure-results`, test jobs передають їх як artifacts, publish job генерує site, GitHub Pages розміщує report, а Playwright traces поки зберігаються окремо як надійний diagnostic artifact.