Hacker News Reader

Comment by cygned | Hacker News Reader

We currently use short-lived feature branches, merged via Pull Requests (+ review / automated testing) into the main development line. This way, we can communicate changes in a detailed manner before they are added to the product and make sure there is no unfished or bad code in the main branch. (The dev team is small, 5-8 devs).

I don't see (yet?), what benefits TBD would provide in such a setup.

View on HN

The linked website includes this workflow under their definition of trunk-based-development. As long as your branches are short-lived and make it into the main line rapidly, it appears to be considered equivalent.

I've seen some commentators say that this doesn't pass their bar for TBD, but I think it's effectively the same thing.

The site does call out "GitHub flow" as being slightly different, but that's because GitHub's description of their model includes deploying the branch to production before merging to master.

Couldn't have said it better myself :)

With TBD you can reduce the overhead of coordination between committers.

Edit for clarification: "Branching in code", á la Feature Toggles is much better, because everything around it can be automated. With CVS branches, you shift that process into an earlier development stage where you need more human collaboration. So TBD can shift the focus of collaboration to things that matter more: the code.

Why can't you automatically merge all the branches for testing? Sure, sometimes it won't cleanly merge, but then again, features behind toggles won't always work well together.

I once wished this were possible too, but in reality it isn't.

With n branches there are n! permutations to test. That's a lot of infrastructure to maintain and computing power to spend and you still don't end up with a single team-blessed deployment artifact that can automatically be promoted for manual testing or release.

Don't get me wrong, feature-toggles are indeed a pain in the ass, but in my experience cherry-picking branches to merge really is much much worse.

And with n feature flags, aren't there also n! permutations to test, that is, each combination of enabled/disabled? If you say no, because you just test features as they get manually enabled, why can't you do the same by manually selecting branches to be merged?

Yes, that complexity does not go away. But you only need one delivery pipeline, with one test/staging environment. Toggling and running acceptance tests against the variations can be automated, but is viable when done manually.

With n feature flags, there are 2^n possibilities to test.

I am very concerned that feature toggles add unnecessary complexity to the code.

With Lisp Macros, for example, that would actually be quite elegant but in a language like JavaScript, we'd end up with a bunch of if'a here and there, wouldn't we? One might simplify it a bit with a different architecture, though.

Long lived branches add complexity too, it's just hidden in GIT. The main issue with feature branches are merge conflicts: they are the most evil operation one can imagine. First you have your code, that you understand. Then you have others code that you have no idea what it does, so first you need to understand it. This might take hours when done properly. Usually people skim over this part BC it's boring. This leads to superficial merges that leads to very very evil and hard to find bugs. And these bugs are super hard to find in git logs, since the merge commit is 2 or more people's code.

Whereas the alternative, feature toggles are much better: first you don't need one for every small thing, add them to bigger features that take weeks to implement. With a team of ~10 developers you should not need more than 2 at one time (if you have more the management is at fault). Then feature toggles enforce modularity: by principle you should use them in as few places as possible, this will make the interface between the new feature and your current app as small as possible. This is a good thing!

I like this best.

It enables you to build your feature and then squash the commits into one idempotent feature commit which keeps commit clutter out of the git logs.

Just keeping your branch rebased daily, one will have minimal problems even on big teams.

I personally love developing on my own branch and having the freedom to experiment without messing stuff up.

Reply on news.ycombinator.com