Hacker News Reader

Comment by onion2k | Hacker News Reader

they don't see any issue with long lived branches

Probably because for most teams there isn't an issue. You only start to see the problems long term branches cause when you have multiple long-term branches in a single repo, and that only happens when your team is sufficiently big to be working on several big things at once or when your product is big enough to use a monorepo where devs on different teams work on the same parts at the same time.

If you're Google or Meta these are very obvious problems that you'll see causing issues regularly. If you're a team of 6 in a corporation or a SaaS then you'll be able to work on a branch for weeks and still be able to merge it without any big problems.

This is my main issue with TBD actually - it's a solution to a problem that few teams actually have. Throwing away a working process like gitflow when you won't see any real benefit doesn't seem like a great idea.

View on HN

To me the argument makes more sense in reverse:

Gitflow solves a problem few teams actually have. Throwing away a working (simpler) process of having a single trunk when there's no real benefit doesn't seem like a great idea.

It seems to me that Gitflow just adds a lot of ceremony of keeping multiple branches somewhat in sync through merges left and right.

I'm fine with the argument of keeping existing processes because they work, whatever they are.

I can tell you that every part of my team’s branch workflow is in service of something else. There is no pointless ceremony. We are a team of four, doing trivial work, in a trivial organisation. You can’t pretend that “you do your work at your desk, get up when you’re done, and hand it over” is just some misstep we all had.

>it's a solution to a problem that few teams actually have

It's more efficient. Why prevent people from reviewing your commits and avoid merging until your feature is 100% complete? With TBD people on your team are able to review changes as they get completed and you can merge them in to avoid future confilcts and to allow others to benefit from your changes too.

Gitflow is also solution to problem few teams actually have.

It is made to have few long term release versions, say you're making a database and need to support customer being major version or two behind for some years.

But if you are just making app for a client you really need just "this is released as stable and running in prod" and some flavours of dev/test environment and that doesn't need much of model to work at all, just prod/test branch with features never landing directly on prod is good enough.

This is true for our small team. The way our changes happen, we rarely get git conflicts, let alone really ugly ones. We have many repos and few team members (basically your example of 6). Even if two or three are working in the same repo (we have one repo that’s bigger than most), there’s enough distinct areas that our changes rarely touch.

In the past I’ve felt a little strange that we don’t “modernize” to adopt TBD, but over doing this for many years with the same size team, it just seems unnecessary because we’re a small team.

Is even easier with a small team to do TBD. Because the amount of integration is reduced the possible need of branches (or their TBD equivalents dark launch/branch by abstraction/feature flags) is greatly reduced. So the branches add ceremony where none is needed.

Though those branches could be needed if you are doing mobile, desktop or library/framework development.

> it's a solution to a problem that few teams actually have.

Or don't acknowledge, acummulate technical debt, because due to being late CR rarely results in any deeper changes in flawed code. Then complain that project is a mess, but management doesn't want to listen about refactoring.

Reply on news.ycombinator.com