Відеобібліотека
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Команди створюють task branch, перевіряють і stage-ять лише потрібний файл, показують staged diff, комітять і публікують branch.
У remote з’являється окрема branch з одним перевіреним commit, готова для Pull Request.
2. Git Workflow у PyCharm/IntelliJ →Для вже опублікованої feature branch поточна Git documentation надає --force-with-lease як захисний варіант. Він не робить history rewrite безпечним автоматично: branch має бути персональною, а переписування — дозволеним командними правилами.
Pull Request представляє запропоновані зміни з branch і дає команді місце для diff, review, checks та рішення про merge.
2. Git Workflow у PyCharm/IntelliJ →Створіть локальну навчальну branch.
Змініть один безпечний файл і перегляньте git diff.
Stage-ніть лише цей файл та перегляньте git diff --cached перед commit.
Commit містить рівно запланований файл і не містить credentials або локальної конфігурації.
Окрема лінія стану репозиторію. git switch <branch> оновлює working tree та index відповідно до вибраної гілки.
Зміни для окремого завдання виконуються в новій branch, створеній від актуальної основної гілки. При створенні варто одразу checkout на неї, після чого перевірити поточну branch перед commit. Це ізолює роботу та спрощує подальший review.
Перед комітом створюється нова гілка. Для командної роботи назва починається з ідентифікатора задачі з Jira, Linear або іншої системи, а далі містить короткий опис. Це пов’язує код з конкретною роботою й спрощує пошук історії. Навіть у сольному проєкті гілки дозволяють відкласти незавершену задачу, повернутися на `main` і почати іншу, не змішуючи зміни.
Багато CI-систем встановлюють стандартну environment variable `CI`. Проєкт читає її, щоб увімкнути CI-специфічні налаштування: headless browser, відсутність локального video recording або іншу політику traces. Це дозволяє зберегти один кодовий шлях із мінімальною конфігураційною різницею. Зміни комітяться й пушаться в task branch, після чого результат перевіряється не лише за загальним статусом, а й за logs конкретної job.
Commit зберігає перевірений знімок змін у локальному repository. Перед push ще раз перевіряються target branch, commit message і файли в diff. Push передає локальні commits до remote repository. Демонстраційний push у відео завершується SSH permission error, що показує окрему вимогу: SSH URL потребує налаштованого SSH key і доступу до repository.
Перед комітом створюється окрема гілка. До diff входять код завантаження конфігурації, `.gitignore` і залежність, але не локальний `.env`. Перед push ще раз перевіряється, що email і пароль не відстежуються. Це важлива межа: `.env` захищає локальні секрети від випадкового Git tracking, але не є менеджером секретів для CI. У CI значення мають надходити з захищених variables/secrets платформи.
iOS test builds поширюються через TestFlight, а build/distribution pipeline може використовувати App Center або platform developer consoles. Потрібно розрізняти dev build, прив'язаний до test/stage backend, і production-configured build, який перевіряють перед release. Тестувальнику рекомендовано мати read access до iOS/Android repositories, щоб бачити diff, перемикатися на feature branch і збирати зміни локально через Xcode чи Android Studio. Feature flags дають змогу вмикати функціонал для ролей, оточень або частини користувачів без розриву між backend і mobile releases. **Актуальність станом на 2026-08-08.** Visual Studio App Center завершив роботу 31 березня 2025 року; тимчасове продовження Analytics & Diagnostics закінчилося 30 червня 2026 року. Згадку у відео слід сприймати як історичну, а новий distribution/diagnostics workflow звіряти з актуальними сервісами платформи ([Microsoft Learn](https://learn.microsoft.com/en-us/appcenter/retirement)).
Після автоматичного рефакторингу переглядається кожен змінений файл. Демонстрація виявляє як нормальні зміни — типи, constants, імпорти — так і небажане видалення файлів та помилку у fixture, яка створила некоректний стан сторінки. AI-агент запускає найменший тест, але сам факт запуску не доводить коректність усієї зміни: треба прочитати failure, перевірити fixture lifecycle і повторити сценарій. Результат оформлюється в окремій гілці та коміті, а не змішується з наступною міграцією інструментів.
Рекомендований цикл: налаштувати безпечний доступ, створити task branch, зробити вузьку зміну, переглянути diff, закомітити, запушити, створити PR і після merge прибрати гілку. Шорткати IDE прискорюють повторювані дії, але не замінюють перевірку змісту. Головне правило безпеки з відео: публікувати код, але не credentials. Якщо є сумнів, перед push потрібно зупинитися й перечитати весь diff.
Великий продукт може мати B2C, B2B, back office, tool-sharing або branch-office застосунки зі спільним core. Структуру automation варто повторювати за реальними domain/app boundaries, а common-код піднімати лише тоді, коли він справді спільний. Для нового automation effort рекомендовано починати з одного repository: розділити усталену систему пізніше простіше, ніж одразу координувати кілька репозиторіїв без перевіреної потреби. Один repository також полегшує справжні end-to-end flows через кілька доменів.