How short should feature branches be?

In 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

---

#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.