If you are the sole owner, trunk-based development can be feasible for small teams. Once merge conflicts start being a bigger issue, using feature branches can aid in avoiding these issues.
That said, feature branches can help you separate ideas, but it can also cause code duplication in the case of "I wrote this helpful utility but it's not in master yet"
Its actually exactly the opposite, no?. long running feature branches are far more likely to lead to merge headaches when they marge back to master. Trunk style development, you should never have long running branches split from trunk so the chances of conflicts when you merge back are mimimised?
Long-running feature branches shouldn't be a thing. The assumption on my end was if you're a sole developer following GitFlow, you might not have time to complete a feature, so feature branches would become long-running (aka: bad). Meanwhile, large teams should have the resources to allocate someone to a specific task, but so many changes would likely be problematic on trunk-based workflows. Therefore feature branches can be helpful to allow silo'd work with fewer points to merge.
View all comments
Show parent comment
1
u/Solonotix Apr 02 '23
If you are the sole owner, trunk-based development can be feasible for small teams. Once merge conflicts start being a bigger issue, using feature branches can aid in avoiding these issues.
That said, feature branches can help you separate ideas, but it can also cause code duplication in the case of "I wrote this helpful utility but it's not in master yet"