git-branches-conventions.md

Git branch conventions

There are 3 types of branches:

1. The master branch
2. Development branches (to be merged into master and then deleted)
3. Releases branches

If your contribution is a hotfix (bug fix on a release already published), follow the hotfix workflow section. In all other cases, you must create a development branch, and submit a pull request to master (possibly in "draft" state until you are done).

Development branches

Development branches must be prefixed with a short name moniker (e.g. gav-my-feature). Development branches must be merged into master and then deleted. If you have to leave your development for a long time, we invite you to push your branch on your fork and to remove it from the official repository, so that the latter is not polluted by too many branches.

Releases branches

This kind of branch should be named perm-TAG, where TAG is the git tag of the corresponding release.

Hotfix workflow

To fix a bug in a release already published (in github releases page), please follow these steps:

1. Create a release branch dedicated to the hotfix release, based on the tag of the last published version.
2. Push a commit that bump the version on the release branch.
3. Submit a PR against master to fix the bug upstream.
4. Once the fix is merged on master, cherry-pick the merge commit on the release branch.
5. Make the git tag on the release branch and follow the delivery process.

Hotfix workflow example runtime hotfix for runtime 1501.

1. Create the release branch perm-runtime-1502, based on tag runtime-1501
2. Push a commit on perm-runtime-1502 that bump spec versions from 1501 to 1502.
3. Submit a PR against master to fix the bug upstream.
4. Once the fix is merged on master, cherry-pick the merge commit on the perm-runtime-1502 branch.
5. Make the git tag on the perm-runtime-1502 branch and follow the delivery process.