Branching Strategies for Release

This post will give you some idea or headache about develop + main branches.

In git, it's important to choose an appropriate branching strategy for you.

There are many aspects there but this post is going to be a small piece of information around release process.

The following table compares the two cases. Choose what makes sense for your project.

Unreleased Commit

A PR merged is committed to master and user can see it.

A PR merged is committed to develop and user can see it, because it's the base branch.

User will see the content regarding unreleased things(But it's okay because we don't have much content on README.md).

Same

User will see the examples regarding unreleased things(This is a problem, but the effect can be minimized if release is frequent enough).

User will see the examples deployed from master, so no problem here.

When managing many versions, branches are straightforward(legacy, master, next).

We have master as a snapshot of lastly released version.
It can be confusing to manage many working branches and release branches, for example, legacy, legacy_release, develop, master, next, next_release.