Git Branching Model

In this package we mostly followed A successful Git branching model proposed by Vincent Driessen. Here are the summary of the branches:

• master: master branch only hosts the released software packages. Only project maintainers have write access on the master branch.

• develop: develop branch is considered the main branch where the source code of HEAD always reflects a state with the latest delivered development changes for the next release.

• supporting branch: There are different supporting branches, three main supporting branches that we suggest the contributors to follow the naming convention includes:

  • feature: we start a new feature branch to add new features to software. The naming convention is iss[issue_number]_short_description. For example, if I need to add rotation of time series to the package and the issue number is 12, iss12_add_rotation can be a valid git branch name. We start it with issue number to go back and take a look at issue details if necessary. Although, feature branches are temporary, this naming convention helps developer to understand the situation while working on the codebase.

  • hotfix: hotfix branches will be only used for fixing a bug on a released package. After fixing the bug the third digit of the version number should be incremented by one. For example, 1.4.2 –> 1.4.3. These branches will be prefixed with hotfix and followed by upcoming version number (e.g., in this case hotfix_1.4.3)

  • release: Release branches support preparation of a new production release. As long as the community is not working on different releases at the same time (e.g., pre-alpha, alpha, beta, stable, and so on), we do not use release branch.