Hacker News Reader

What I don't understand about this model is

1. What is the relationship between the code in the main branch and the code in the develop branch?

2. What assurance does the testing on the develop branch provide that the feature branch is suitable to merge into the main branch?

I mean, presumably you've got main and develop because they need to be different. But then, because they're different, you're never really testing the code that you actually deploy. Superficially, it seems both more complicated and less reliable than trunk-based development.

What am I missing? Why would this way of working be helpful?

The develop branch is main + feature branches currently in qa.

> But then, because they're different, you're never really testing the code that you actually deploy.

That's true, and I alluded to it in my comment. It's conceivable that feature-1 and feature-2 are simultaneously in develop, feature-1 gets tested successfully and is merged into main; and then it turns out you needed feature-2 to actually fulfill all requirements. Seems like it'd happen all the time, but in practice, it just doesn't. Probably a combination of unit tests, backend code being written in a static language, and developers, qa, and pms using their head.

> Why would this way of working be helpful?

Having little experience with anything else, it's difficult for me to say. It seems quite flexible: we release individual features or, sometimes, related features that are compounded into a feature branch.

Main essentially never breaks, and it's nice that you can essentially deploy it whenever you want without explicitly packaging a version and testing it. That seems to be the idea behind trunk-based development, too.

But then, develop does break occasionally (i.e. a bug was discovered during testing), and it's nice that this is allowed, as well. Having to revert a feature branch from trunk because a bug was discovered sounds terrible, and also what if you released trunk in the meantime? It sounds to me like it could only work if the feature branches itself are the subject of QA (and then you have a similar problem as testing our develop branch).

Thanks, this mostly makes sense now.

> The develop branch is main + feature branches currently in qa.

Is any work done to ensure this, or is it just a byproduct of the way of working? I'm struggling to understand how it would just happen automatically.

Well, it's manual in that when a developer thinks they're done, they open a pull request from feature branch to develop. That's where code review takes place, and as such it's a core part of the workflow. Failing qa might mean additional commits on the feature branch and another pull request to develop. (Develop should really be called testing or qa; historical reasons.)

It sounds to me like the relationship between dev and main is maintained implicitly. At some point dev and main were the same, and from there, any delta that is applied to dev is eventually either applied to main (if it passes QA) or removed from dev (if it fails). If you follow this pattern forever, dev should always be main plus patches currently in QA.

One more question. What if instead of this dev branch people just asked the QA system to run on their feature branches? Would that generate too much work?

I'm imagining that the flow you describe is some kind of convenient or less expensive version of that.

That's pretty much spot on.

Git having default branch name be "dev" instead of master/main would really clear a lot of misunderstandings and people thinking "main" branch is the stable one.

No need to be so harsh, they're not proclaiming anything just explaining their routine.

I agree though that testing the feature branch on the develop branch is not the same thing as that feature branch living in main, because some other feature branch in develop branch may be indirectly affecting the original feature branch.

There's no harshness there at all, I'm just being clear about what I don't understand and how it superficially looks and asking what am I missing.

I barely use git in any meaningful way so these questions are coming purely from outsider curiosity.

Maybe I misunderstood your description, but does 'develop' not ever merge to 'main' directly? Your description sounded like QA could for example test 'develop' which is main + featureA + featureB, give that a green light, and then have new main be main + featureA (which has been never tested). That does sound bit dangerous.

(As an embedded developer, it would be bliss to experience 'develop gets deployed semi-hourly'...)

No, develop never gets merged to main. In fact, I've been meaning to add a dummy commit to develop and a commit hook that declines it being merged to main, to ensure nobody merges it by accident. One of these days...

You've identified what I'd call the main weakness, but in practice it hasn't been an issue. I've discussed it in a bit more detail in a sibling post. Ymmv.

Gitflow and TBD are just two of the many possible ways to use Git. Several companies (such as yours) use other systems that have no name. And that is fine. We don't need to name every possible variation of a Git model.

If it doesn't have a name, I might give it one and document it more formally than in a hacker news comment. I was under the impression that most teams implement one of a handful of standard models. But it's possible that you're right that there's more variation to it than I thought.

We use a similar model, but only one "main" branch, which get a tag when released.

I would call it trunk based development, since feature branches are short lived.. Most MR are just 1 or 2 commits. Just part of our review process.

How often do you release? Is there any manual qa (as opposed to unit or integrating tests)? Does a bug in one feature block the release of others (because it means main has a bug)?

I've definitely seen the same model used. Small company also.