Branching Strategy

Branching model

Let's use the GitFlow branching model.

Introducing GitFlow
A successful Git branching model

General considerations

Feature branches

1. When starting work on a new feature, branch off from the develop branch. (git checkout -b feature/name-feature develop). Branch naming convention: feature/JIRA-ID
2. Finished features may be merged into the develop branch to definitely add them to the upcoming release.

Release branches

1. Release branches support preparation of a new production release. They allow for last-minute dotting of i’s and crossing t’s. Furthermore, they allow for minor bug fixes and preparing meta-data for a release (version number, build dates, etc.). By doing all of this work on a release branch, the develop branch is cleared to receive features for the next big release. May branch off from: develop - Must merge back into: develop and master - Branch naming convention: release/... - e.g.: release/SPRINT-01-rc1
2. The version number assignment is done on the start of the release branch and is carried out by the project’s rules on version number bumping.
3. The release branch may exist until the release may be rolled out definitely. During that time, bug fixes may be applied in this branch (rather than on the develop branch). Adding large new features here is strictly prohibited. They must be merged into develop, and therefore, wait for the next big release.
4. While the bugs in the release branch are solved and new pre-release versions are obtained, the version of the bugs will be modified in the pakages.json. e.g .: version SPRINT-01-rc1 after fix some bugs the new version is SPRINT-01-rc2.
5. When the state of the release branch is ready to become a real release, some actions need to be carried out. First, the release branch is merged into master (since every commit on master is a new release by definition, remember). Next, that commit on master must be tagged for easy future reference to this historical version, in this case the tag will be Release-1.0.0. Finally, the changes made on the release branch need to be merged back into develop, so that future releases also contain these bug fixes.

Hotfix branches

1. When a critical bug in a production version must be resolved immediately, a hotfix branch may be branched off from the corresponding tag on the master branch that marks the production version.
2. Don’t forget to bump the version number after branching off!. e.g: master version: 1.0.0 - hotfix version: 1.0.1
3. When finished, the bugfix needs to be merged back into master, but also needs to be merged back into develop, in order to safeguard that the bugfix is included in the next release as well. This is completely similar to how release branches are finished.
4. Branching naming convention for fixes is fix/JIRA-ID - e.g.: fix/BOA-1234

Git commits

Make sure to add a descriptive message when committing changes. Messages should include JIRA-ID and a description of the change introduced. For example: SEC-1234: refactoring unit test

Semantic Versioning

Let's use the Semantic Versioning Specification. SemVer

Summary

Given a version number MAJOR.MINOR.PATCH+BUILD, increment the:

1. MAJOR version when you make incompatible API changes,
2. MINOR version when you add functionality in a backwards-compatible manner, and
3. PATCH version when you make backwards-compatible bug fixes. Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.
4. BUILD number when a new build in TeamCity is executed