Gitflow
Main branch is where production releases take places. Committing directly to main branch is not allowed and all the changes have to go thought rc branch (except hotfixes).
rc branch is for release-candidate versions. Every feature branch should be merged into rc branch. After that pre-release version is created and ready to use.
Once the release is ready to ship, it will get merged it into main.
Release cycle is last Thursday every month. Then rc branch is merged into main and tagged. TEDI components have to meet TEDI DoD, when community components doesn't have that high level standard.
Release notes are generated by semantic-versioning library.
Each new feature should reside in its own branch. But, instead of branching off of main, feature branches use rc as their parent branch. When a feature is complete, it gets merged back into rc. Features should never interact directly with main.
All feature branches have test environment at GitHub pages, so developers can test before release. For TEDI-READY components it is mandatory.
git checkout rc
git checkout -b feat/123-some-new-component
Maintenance or hotfix branches are used to quickly patch production releases. Hotfix branches are a lot like feature branches except they're based on main instead of rc. This is the only branch that should fork directly off of main. As soon as the fix is complete, it should be merged into main (and the current release branch), and main will get tagged by semantic-versioning.
Having a dedicated line of development for bug fixes lets your team address issues without interrupting the rest of the workflow or waiting for the next release cycle. You can think of maintenance branches as ad hoc release branches that work directly with main.
It is temporary branch for migration from GitLab to GitHub for syncing the work that is done parallel in GitLab. Will be removed in the future.