There is a CI job that merges release to main after every commit in release. Unfortunately it did not trigger since there has been a change in the branches settings for push requirements.

The error was: Changes must be made through a pull request. // See: https://docs.github.com/rest/branches/branches#merge-a-branch I have changed the settings to solve this.

The rationale for having a release branch is that we wanted to have an state in master that was different to the release. This was specially important for features that took multiple PRs. Having a release branch gives us control into what goes in a release (which it was needed).

Right now after 0.4.0, when I test merge release back to main, I see many duplicate commits. How to solve that?

Is it OK that we don't merge release back to main after semantic release makes its version commit? Methinks right now we don't get that audo merge back until we decide to make another pr/merge/release.

There are not duplicated commits, there are either backported commits to the release branch (that was the reason of having a release branch) or you are seeing a merge commit. We want to always merge release to main (we do an -s ours merge) to avoid future merge conflicts.

Is it OK that we don't automaticly merge release back to main after semantic release makes its version commit?

Do we need to merge release back to main for 0.4.0 right now?

Is it OK that we don't automaticly merge release back to main after semantic release makes its version commit?

It is safer to merge after releases so that releases are reachable from main and also we avoid potential merge conflicts in the future.

Do we need to merge release back to main for 0.4.0 right now?

it is already merged 1c9359e

You might want to close this since this was solved by restoring the github branch settings.