Наскільки короткими мають бути feature-гілки?

У контексті Trunk-Based Development feature-гілки мають бути максимально короткоживучими - від кількох годин до 1-2 днів.

Простіше кажучи: якщо гілка живе довше пари днів - це вже антипатерн для TBD.

---

#Чому feature-гілки мають бути короткими

Філософія TBD - рання і часта інтеграція. Довгоживучі гілки призводять до:

• великих PR
• складних merge-конфліктів
• пізнього виявлення помилок

---

#Практичні орієнтири

#Ідеально

• кілька годин
• одна логічна частина задачі
• маленький PR (десятки рядків)

#Прийнятно

• до 1 дня
• максимум 1-2 дні у рідкісних випадках

#Погано (для TBD)

• тиждень
• декілька тижнів
• «поки не закінчу всю фічу»

---

#А як робити великі фічі?

У TBD не роблять великі фічі в одній гілці. Замість цього:

• розбивають задачу на маленькі кроки
• використовують feature flags
• комітять частинами в trunk
• код може бути в main, але вимкнений

---

#Порівняння з Feature Branch Workflow

---

#Чому це важливо для співбесіди

Часто очікують почути не цифру, а ідею:

Feature-гілки мають жити рівно стільки, щоб не втрачалася синхронізація з trunk.

---

#Короткий відповідь для співбесіди

У Trunk-Based Development feature-гілки мають бути дуже короткими - зазвичай кілька годин, максимум 1-2 дні, щоб зміни швидко інтегрувалися в trunk і не накопичувалися конфлікти.