alt Hacker NewsI am working with main/master for years now, and there's one problem you don't have with develop: Whenever you merge something into master, it kind of blocks the next release until its (non-continuous) QA is done. If your changes are somewhat independent, you can cherry-pick them from develop into master in an arbitrary order and call that a release whenever you want to.
Replies
I worked at a place that had Gitlab review apps set up. Where the QA people could just click a button and it would create an instance of the app with just that PR on it. Then they could test, approve, and kill the instance.
Then you can merge to master and it's immediately ready to go.
> Whenever you merge something into master, it kind of blocks the next release until its (non-continuous) QA is done.
That's what tags are for, QA tests the tagged release, then that gets released. Master can continue changing up until the next tag, then QA has another thing to test.
Yes, you have to include QA in the continuous integration process for it to work. That means at any time you can just tag the top of the master branch to cut a release, or do continuous delivery if it makes sense (so no tags at all).
It sounds like you are doing a monorepo type thing. Git does work best and was designed for multiple/independent repos.
What's the difference between what you describe, and continuously merging things into main and cutting releases from a branch called stable?