Show HN: Why you should not use feature branches
1–10 of 45 posts
Re: Show HN: Why you should not use feature branches
#2Someone forgot about continuously merging master to feature branch to keep the merge simple.
Re: Show HN: Why you should not use feature branches
#3 - "Show HN" when there is nothing really to show
- Submitted by the author of the post
- Author of the post is founder of company
- Provocative, click-baity Headline
Re: Show HN: Why you should not use feature branches
#4"Your feature branch is your own perfect garden and you can keep it clean and shiny. But it is separated from the other gardens of your team. The more you work apart, the harder it is to reconcile."
But then, later in the article,
"It is 2019. If you don’t have a continuous integration setup that builds and runs tests automatically … then set it up yesterday. If you break anything you’ll be notified before it becomes a problem for the whole team."
Which, in my experience, greatly helps to mitigate the "it works on my machine" factor that arises from having a new branch for each task.
I appreciate the perspective, but I've found working with feature branches much better than trunk-based development. I'll take my merge conflicts any day. :-)
Re: Show HN: Why you should not use feature branches
#5If one read Martin Fowler about feature branching, https://martinfowler.com/bliki/FeatureBranch.html and articles from Jez Humble both agree on that one should use trunk based development and use feature toggles in most cases for development.
Re: Show HN: Why you should not use feature branches
#6One of the issues with feature branches is that long-lived feature branches easily go stale, and each day that passes by makes it riskier to merge them into master.
While I agree with the author on the general idea of trunk-based development (and feature switches), can't we get the best of both worlds by allowing short-lived pull requests where code review can happen?
I'd be curious to hear from teams here who push directly to master and how this workflow works for them.
Re: Show HN: Why you should not use feature branches
#7Your git strategy should depends on your business release cycle and priorities. In this case, it's a trade-off between dev branch stability and development speed.
With trunk-based development, everyone sees everyone else's work in progress and it's easier to integrate different features together. With feature branches, however, dev is more stable and there's more responsibility on merging to branch back to dev.
Are you deploying to public a few times a day like a web service, or are you working towards an early release, like a AAA game? Does your team sit together in one room, collaborating with one another, other do they take completely independent task and do them remotely, working from all across the globe, with the only point of interaction being a pull request once or twice a week?
It's impossible to say what's better or what's worse without these priors.
Re: Show HN: Why you should not use feature branches
#8It's more that feature branches should be rebased instead of merging the main branch into it (like most developers unfortunately do)
[pull]
rebase = true
This way, the git history is linear, clean and readable
Re: Show HN: Why you should not use feature branches
#9Not really a show HN.
Also, rebase master into your feature branches regularly.
Re: Show HN: Why you should not use feature branches
#10One of the issues with feature branches is that long-lived feature branches easily go stale, and each day that passes by makes it riskier to merge them into master. While I agree with the author on the general idea of trunk-based development (and feature switches), can't we get the best of both worlds by allowing short-lived pull requests where code review can happen? I'd be curious to hear from teams here who push d…
Not doing any of this myself, but the keyword here is "rebase".
(But yeah, there's a problem with reduced testing during feature development. What if a feature branch breaks the main branch and it does not get noted during feature development? I'd argue if it affects the core then it's not strictly a "feature")