Suggest an editImprove this articleRefine the answer for “How short should feature branches be?”. Your changes go to moderation before they’re published.Approval requiredContentWhat you’re changing🇺🇸EN🇺🇦UAPreviewTitle (EN)Short answer (EN)In the context of **Trunk-Based Development**, feature branches should be as short-lived as possible, from a few hours to 1-2 days. **Key point:** feature branches should live exactly long enough not to lose synchronization with the trunk.Shown above the full answer for quick recall.Answer (EN)ImageIn the context of **Trunk-Based Development**, feature branches should be **as short-lived as possible**, **from a few hours to 1-2 days**. In simpler terms: *if a branch lives longer than a couple of days, it is already an anti-pattern for TBD.* --- ## Why feature branches should be short The philosophy of TBD is **early and frequent integration**. Long-lived branches lead to: - large PRs - complex merge conflicts - late discovery of bugs --- ## Practical guidelines ### Ideal - **a few hours** - one logical part of a task - a small PR (tens of lines) ### Acceptable - **up to 1 day** - at most **1-2 days** in rare cases ### Bad (for TBD) - a week - several weeks - "until I finish the whole feature" --- ## So how do you build large features? In TBD **large features are not built in a single branch**. Instead: - the task is broken into small steps - **feature flags** are used - commits are made in parts to the trunk - the code can be in `main`, but disabled --- ## Comparison with Feature Branch Workflow | Workflow | Feature branch lifetime | |---|---| | Feature Branch Workflow | days / weeks | | Gitflow | days / weeks | | Trunk-Based Development | hours / 1-2 days | --- ## Why this matters for an interview Interviewers often expect to hear not a number but the **idea**: > **Feature branches should live exactly long enough not to lose synchronization with the trunk.** --- ## Short answer for an interview > **In Trunk-Based Development, feature branches should be very short, usually a few hours, at most 1-2 days, so that changes quickly integrate into the trunk and conflicts do not accumulate.**For the reviewerNote to the moderator (optional)Visible only to the moderator. Helps review go faster.