I don't understand the release branches

I'm used to git-flow, so I'm a bit puzzled by the current workflow.

When are commits in a release branch merged into the dev branch?

The release branches are stable and that's where releases are built from. Dev is for development and pre-releases might also be built from there initially. But as we get near the final release, pre-releases get built from release branches too.

Ok, so whenever a release (not a pre-release) is created, the code will be merged back to dev?

I think the current dev branch has all commits from the release-1.6 branch but not all commits from release-1.7.

And when is master updated? It's probably not that important since releases are created from other branches than master. Which is something I'm not used to. That's why this is a bit confusing to me.

Yes it's not really standard, it's partly based on git-flow but less strict, since usually there's just a team of one working on the project :slight_smile:

Master is more or less abandoned at this stage since the stable branches are the release ones. In theory we could merge all the release branches to it, except for the current pre-release (1.7) and that would give us a stable master. But in fact, as of now, it would be the same as release-1.6.

I think dev has all the commits from 1.6 and 1.7, but if not I'll merge them at some point.

Thanks for the info. Now it makes a bit more sense. I still don't understand the dev branch then.

e.g. commit df1df6dc1 from release-1.7 is not in dev.

Sorry for being so annoying, but I really want to understand it. :slight_smile:

Merging to dev is not automated, I just do it manually from time to time, so in this case I haven't done it if that commit is missing. If you need it on dev though, feel free to do the merge.

Aha, ok. No, I don't really need that commit, but I'm used to have all the dev work done on the dev branch, unless there are incompatible releases. In which case release branches are "misused" as separate master branches. And in such a case dev HEAD would always have the most recent commit from the current release.

But what happens, if a previous release is incompatible (has a different codebase). In that case you can't merge that release-branch back into dev ever, because it would revert the new changes of the current release that are incompatibel with the previous.

As I said, I'm a bit puzzled. I'm finally getting better after being sick for 2.5 weeks, so my brain is not working at a 100%.

Are you talking about merge conflicts? It can happen but it can never be that bad that it can't be merged anymore.

Not necessarily conflicts.

As an example: you have two releases A and B, and a dev branch. The dev branch is on par with release branch B.
So after release A you renamed a settings variable and had to change 4 files.
Now you go back to release A, and have to fix one file that uses the old settings variable.

When you merge A into dev, you will have 3 files with the new settings variable and 1 file with the old settings variable. There was no merge conflict, but the code is broken.

I've seen things like this happen and most of the time you find the error only much later.

Thus merging 2 incompatible branches into a 3rd one can be very tricky. This is why incompatible branches usually use cherry-picking (from dev) and are forbidden to be merged back into dev (all branches that are not the latest release branch).

As I said, my thought processes are still a bit off, so I might have missed something, but I think I got it right.

No that makes sense and could happen. But usually by the time there's a release branch, most major features are already in, so it's just bug fixes and small tweaks afterwards, which means the risk of something like you describe is quite low.

1 Like