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

21–30 of 45 posts

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

#21

Post by mikekchar »

jstimpfle wrote: post #18
mikekchar wrote: post #17

I like TBD -- a lot. However there are a couple of problems with it. If your team is not collocated in a time zone then you'll one one guy (me, for instance) who will push 8 hours of development into trunk without anyone else getting a chance to look at it. The same thing happens if you have someone who just "disappears" for a day or two and effectively has a feature branch. You need to have discipline on your team t…

> (I like to push at least every 20 minutes) That sounds extreme to me. What kind of development do you do that makes this possible? I rarely finish something within 20 minutes. Often, I'm thinking about the right way to do something for a day or longer before I decide to push some results. (UPDATE, before I even start to write some code!)

Intermediate results are fine as long as the tests are passing. If you push, then your teammates will see what you are doing and one of them can give you advice if they think you are going in a disadvantageous direction.

If you hold the code out for a whole day, there is no way for anyone else to know what you are doing (unless you interrupt them to tell them, or they somehow know to ask you). On a well functioning TBD team with true CI, everybody knows what everybody else is doing because they are constantly looking at diffs when they pull trunk.

But yes, it is extreme ;-) It's one of the 12 XP practices (continuous integration). Interestingly, the original idea behind CI servers was that when you push to trunk, you were never sure if there would be an integration problem. So if someone pulled trunk, they might get garbage. So the CI server was there so that you could get a visual indication of whether or not it was safe to pull trunk. And if it went red the whole team would instantly take a look to see what happened. It's a team based approach rather than an individual approach.

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

#22

Post by AstralStorm »

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

And you lose information about when given code was done. (Commit date and parent) Which is crucial to know if any given piece is stale in a bigger project. Stale code may be rotten code.

Why is a linear history better again? If you cannot read history graphs, perhaps you should really not use a VCS where merging happens.

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

#23

Post by AstralStorm »

turdnagel wrote: post #9

Not really a show HN. Also, rebase master into your feature branches regularly.

I recommend pulling instead. That way you do not lose information on when given code was done and conflict resolution is visible, making hacks like git-rerere less required and automated merging tools more potent.

This is really important when there are parallel feature branches and even more so when features are codependent.

E.g. if feature a depends on feature b, if you rebase feature a you cannot just pull it into feature b as there will be duplicate commits.

If you want nice lines you should hire a painter. If you want easy merges, merge instead of rebasing.

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

#24

Post by jstimpfle »

AstralStorm wrote: post #19
jstimpfle wrote: post #15

I guess the main advantage of feature branches is that you can easily drop them if it turns out the feature was a bad idea or too hard to implement. The advantage of trunk based development would be that the feature gets potentially more testing. Same goes for interactions with the main line code - if feature development breaks the core in subtle ways, it will be noticed earlier using trunk based development.

It will be noticed - by angry users. Which is why untested continuous deployment is madness. When you do checkpoint regular releases done often, you get a chance to smoketest and block a release. Automated smoke tests only go so far in fixing this - if you could cheaply, reliably and completely fully automate testing, everyone would already do that. About the only way to do continuous deployment is to not deploy into…

Yes - in my case the "users" are just my colleagues (and yes, they could get angry, but the feedback can be worth it).

I believe that "trunk" is not commonly meant to be immediately deployed to users. But, maybe things are different in the web world, where "deploy" is as easy as "upload to server"?

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

#25

Post by AstralStorm »

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

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

#26

Post by aequitas »

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.

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

#27

Post by rurban »

rejschaap wrote: post #11
maushu wrote: post #2

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

If everyone is working in a feature branch and only bug fixes are done in master, then most of the merges will be simple. However, when a feature is done and merged to master, all the feature branches need to merge the work and that merge will be disproportionately difficult. kennethh posted a link that explains this well: https://martinfowler.com/bliki/FeatureBranch.html

Only if you don't know rerere, and don't use it immediately after updating master. I carry tons of feature branches with me, which are automatically rebased. Only once or twice a year I need to fixup things a bit, and those things are the things I immediately worked on, so I know for sure how to merge it. Everything is scripted.

If you let them stall it becomes a mess, sure. If do it properly it's trivial.

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

#28

Post by ScottFree »

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 alternative I've found is to over-communicate every push to your co-worker because it requires him to stash his changes, delete his local branch, pull down the "new" remote branch and re-apply his changes.

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

#29

Post by vidanay »

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.

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

#30

Post by Grue3 »

jstimpfle wrote: post #18
mikekchar wrote: post #17

I like TBD -- a lot. However there are a couple of problems with it. If your team is not collocated in a time zone then you'll one one guy (me, for instance) who will push 8 hours of development into trunk without anyone else getting a chance to look at it. The same thing happens if you have someone who just "disappears" for a day or two and effectively has a feature branch. You need to have discipline on your team t…

> (I like to push at least every 20 minutes) That sounds extreme to me. What kind of development do you do that makes this possible? I rarely finish something within 20 minutes. Often, I'm thinking about the right way to do something for a day or longer before I decide to push some results. (UPDATE, before I even start to write some code!)

I'd even go as far as to say that any code that was written in the span of 20 minutes can't possibly be good code, and doesn't deserve to be in master. The code quality and commit history must be pretty terrible in a project like this.
Post reply on HN