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