Запропонувати правкуПокращити цю статтюДопрацюйте відповідь до «У чому суть Feature Branch Workflow?». Ваші зміни проходять модерацію перед публікацією.Потрібне підтвердженняКонтентЩо ви змінюєте🇺🇸EN🇺🇦UAПереглядЗаголовок (UA)Коротка відповідь (UA)**Feature Branch Workflow** - це Git workflow, при якому кожна нова задача (фіча, багфікс, покращення) розробляється в окремій гілці, а основна гілка завжди залишається стабільною. **Ключове:** зміни потрапляють до основної гілки тільки через Pull Request, що забезпечує ізоляцію, ревʼю та стабільність.Показується над повною відповіддю для швидкого нагадування.Відповідь (UA)Зображення**Feature Branch Workflow** - це Git workflow, при якому **кожна нова задача (фіча, багфікс, покращення) розробляється в окремій гілці**, а основна гілка завжди залишається стабільною. Простіше кажучи: *«Одна задача - одна гілка»*. --- ## Суть Feature Branch Workflow Головна ідея: - `main` (або `master`) - **стабільний код** - для кожної задачі створюється **окрема feature-гілка** - розробка ведеться **тільки у feature-гілках** - код потрапляє в `main` **через Pull Request** --- ## Типовий процес роботи 1. Створюємо гілку від `main` ```bash git checkout -b feature/login ``` 2. Працюємо над задачею і робимо коміти ```bash git commit ``` 3. Пушимо гілку у віддалений репозиторій ```bash git push origin feature/login ``` 4. Відкриваємо Pull Request у `main` - проходить code review - запускаються тести / CI 5. Вливаємо зміни в `main` 6. Видаляємо feature-гілку --- ## Чому цей workflow настільки популярний ### Ізоляція задач - кожна фіча розробляється окремо - зміни не заважають іншим - можна безпечно експериментувати --- ### Безпека основної гілки - `main` завжди в робочому стані - не можна випадково зламати продакшн --- ### Зручний code review - увесь код задачі зібраний в одному Pull Request - легко зрозуміти, що і навіщо змінювалося --- ### Добре масштабується - підходить для маленьких і великих команд - легко додати правила: CI, approvals, лінтери --- ## Merge або rebase у Feature Branch Workflow Зазвичай: - merge виконується через Pull Request - rebase використовується **локально**, щоб оновити feature-гілку Важливо: - `main` **ніколи не ребейзять** --- ## Плюси і мінуси ### Плюси - простий і зрозумілий - безпечний - відмінно працює з Pull Request - де-факто стандарт у галузі ### Мінуси - з'являється багато гілок - без дисципліни feature-гілки можуть жити занадто довго - історія може містити merge-коміти --- ## Короткий відповідь для співбесіди > **Feature Branch Workflow - це підхід, при якому кожна задача розробляється в окремій гілці, а зміни потрапляють в основну гілку тільки через Pull Request, що забезпечує ізоляцію, ревʼю та стабільність.**Для рев’юераПримітка для модератора (необов’язково)Бачить лише модератор. Прискорює рев’ю.