8.2 Integrated Branch Model
||Tested versions are merged to master during release. The version is also tagged.
||Reviewed code is merged to the version branch. Code in a version branch has been reviewed, but may be untested. Version branches only exists for upcoming versions, after release the branch is closed. Sometimes the branch can have a name instead of a version number, in this case a version number will be assigned on release.
||Branches starting with an issue ID contain the work in progress for that issue.
Please use the following procedure when developing for Integrated:
- All development must be linked to an issue, so create an issue first if it's not there yet. (new issues will pull requests will always be reviewed soon)
- If you don't have write access to the Integrated repositories, you'll have to make a fork of the repository first. If you have write access (only for regular contributors) you can skip this step.
- Every issue needs it's own branch. Create a new branch based on the version branch. You can see the version in Jira ("Fix version"). If your work has dependencies with unmerged code, you can create a new branche based on the other issue branche. This needs to be commented in the issue. Please note that the branche name always starts with the issue number. This way it will be attached to the Jira issue automatically.
- If you have Jira development access, always use the Jira “Create branch” link when creating branch and use the proposed branch name. The branch will be linked to the Jira issue.
- Always start your description with the issue ID when committing to make sure every commit is linked to an issue.
- When you resolve your issue, you need to create a pull request to the develop branch. If you are assigned as developer in Jira please transition the Jira issue to “Done”. If not, please add a comment that you created the pull request.