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?

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

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.

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

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.

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.