Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Why you should not use feature branches

fire.ci

Post reply on HN
Print view View original

31–40 of 45 posts

Re: Show HN: Why you should not use feature branches

#31

Post by timw4mail »

AstralStorm wrote: post #25
kennethh wrote: post #5

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

Sure, do end up with hundreds of commits where any given combination of feature flags fails, except sometimes the default. Seriously, this is the quintessential Gentoo Linux problem. Nobody can test all the combinations making the flags almost instantly useless. (And some essentially forced on.)

Having used Gentoo for a long time I haven't seen it be that big of an issue.

But I can definitely see too many feature flags leading to a byzantine web of untestable combinations.

Re: Show HN: Why you should not use feature branches

#32

Post by 11235813213455 »

jph wrote: post #14

A "feature branch" means something much different to my teams. A feature branch for us is a short-life topic branch, and typically for one use case, kanban card, etc. We use short-life topic branches for each feature, each bug fix, each infrastructure-as-code change, each documentation update, etc. We prefer short-life topic branches vs. committing to the `master` branch (or equivalent `develop` branch) because of mu…

Do you "force" push sometimes to this kind of feature branch you describe? I often `push -f` to my own feature branches, I think it's manageable also in a shared branch, but less easily

Re: Show HN: Why you should not use feature branches

#33

Post by jph »

vidanay wrote: post #29
jph wrote: post #14

A "feature branch" means something much different to my teams. A feature branch for us is a short-life topic branch, and typically for one use case, kanban card, etc. We use short-life topic branches for each feature, each bug fix, each infrastructure-as-code change, each documentation update, etc. We prefer short-life topic branches vs. committing to the `master` branch (or equivalent `develop` branch) because of mu…

How do you name your topic branches? We previously used a bug tracking system in parallel with this same process, so we used ticket numbers as the prefix for branch names. On our current project, we are using Trello as the driving tool which obviously doesn't have the simple numbers so we end up with odd inscrutable branch names and I haven't yet found a good way to normalize them.

Each team is free to choose their own way. Personally I like topic branch names that are read like a present tense imperative commit messages e.g. add_feature_for_user_to_like_a_post, fix_relation_between_a user_and_a_post, optimize_search_speed_for_a_user_to_see_posts. The names are long and meaningful. Autocompletion makes these work well.

Our git commit message conventions are:

https://github.com/joelparkerhenderson/git_commit_message

To store info about metadata, such as task board number, we edit the branch description, and enable the description to go into the merge message.

A good short intro to branch descriptions:

https://ericjmritz.wordpress.com/2015/11/13/using-branch-des...

Re: Show HN: Why you should not use feature branches

#34

Post by jpdel »

rglullis wrote: post #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 We are better than that, HN.

Not sure how the title is provocative? Even less click baity. And is there a rule I am not aware of against submitting my own posts?

Re: Show HN: Why you should not use feature branches

#35

Post by jpdel »

arnvald wrote: post #13

I've tried trunk-based development before, and while it provides certain benefits, I don't think it's a silver bullet. > Why you should not use feature branches > Keep reading, all the objections you can think of are wrong. The tone of the title and some parts of articles suggests that trunk-based development is objectively better than feature branches. I feel that it's rather a matter of opinion. You might want to t…

Fair enough. You have a valid point on "your objections are not valid" is not the right tone. I'll edit to highlight that feature branches have their benefits in some cases. Thanks for reading!

Re: Show HN: Why you should not use feature branches

#36

Post by pxue »

ScottFree wrote: post #28
11235813213455 wrote: post #8

It's more that feature branches should be rebased instead of merging the main branch into it (like most developers unfortunately do) [pull] rebase = true in your ~/.gitconfig, and just pull the branch your forked from This way, the git history is linear, clean and readable

Rebase is so terrible and not because of the lost commit history (most of which deserves to be lost, imho. git merge history is too verbose and oftentimes not useful). My issue with rebase is that as soon as you want a single other person to commit code to that branch, you can no longer rebase. Everything must be merged from that point on, otherwise the histories diverge and you wind up in rebase/merge hell. The only…

use interactive rebase?

Re: Show HN: Why you should not use feature branches

#37

Post by jpdel »

AstralStorm wrote: post #25
kennethh wrote: post #5

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

Sure, do end up with hundreds of commits where any given combination of feature flags fails, except sometimes the default. Seriously, this is the quintessential Gentoo Linux problem. Nobody can test all the combinations making the flags almost instantly useless. (And some essentially forced on.)

Agree that feature flags count should not explode because you can never test all combinations. Feature toggles should drive the life span of a feature from start of development to "adopted and becomes the default" or "rejected and we scrap it all out". At the end of the day the number of feature toggles should remain relatively low.

Re: Show HN: Why you should not use feature branches

#38

Post by ulisesrmzroche »

aequitas wrote: post #26
maushu wrote: post #2

Someone forgot about continuously merging master to feature branch to keep the merge simple.

Please don't merge continuously, rebase instead. You have to handle the conflict one way or the other. But at least rebasing doesn't give you an incomprehensible git history filled with spaghetti and extraneous merge commits.

You can always squash the branch before merging back to master.

Re: Show HN: Why you should not use feature branches

#39

Post by gus_massa »

rglullis wrote: post #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 We are better than that, HN.

Submitting your own stuff is OK here. You can add some comment explaining that you are willing to answer questions, but it is optional. Anyway, most people here will assume that the owner will read the comments sooner or later. (Reposting and reposting and reposting your stuff is not OK.)

Anyway, this is an article that is on-topic, but it is not a good ShowHN. From https://news.ycombinator.com/showhn.html

> Blog posts, sign-up pages, and fundraisers can't be tried out, so they can't be Show HNs.

(Disclaimer: I prefer rebasing.)

Re: Show HN: Why you should not use feature branches

#40

Post by arnvald »

jpdel wrote: post #35
arnvald wrote: post #13

I've tried trunk-based development before, and while it provides certain benefits, I don't think it's a silver bullet. > Why you should not use feature branches > Keep reading, all the objections you can think of are wrong. The tone of the title and some parts of articles suggests that trunk-based development is objectively better than feature branches. I feel that it's rather a matter of opinion. You might want to t…

Fair enough. You have a valid point on "your objections are not valid" is not the right tone. I'll edit to highlight that feature branches have their benefits in some cases. Thanks for reading!

Thank you for considering my comment!
Post reply on HN