Gitflow workflow

As you can imagine there are many workflows possible with such a flexible system as Git. To support us in the development process we chose to use the Gitflow workflow. We will discuss the guidelines of this workflow here. To find out more details about this workflow please have a look at the tutorial by atlassian:

https://www.atlassian.com/git/tutorials/comparing-workflows#gitflow-workflow

Historical branches

When utilizing the Gitflow workflow our repository will have two “historical” branches:

• master (stable)
• development (unstable)

This basically means that the versions we release (considered stable) will reside on the master branch and have a tag containing the version number. The development branch will be used to collect our bugfixes and features until we are ready to release a new version.

Feature branches

When we start working on a bugfix or new feature we will create a new branch based on the development branch. It is best to prefix the branch name with either “bugfix” or “feature”.

When we are finished working on the bugfix or feature we will open a new pull request to merge our changes into the development branch.

Release branches

When all features and bugfixes have been merged to the development branch it is time to create a release branch. The release branch can then be tested and any bugs or improvements can be merged to the release branch.

When the release branch is good enough to deploy it is merged into master and development and a tag will be made on the master branch. The master branch can then be used to deploy to production.

Maintenance branches

It can happen that a user will find a bug in the production version that prevents the user from using the application. In this case an urgent fix is required.

The version tag should be used to checkout the state of the files like they are on the production environment and create a new branch from there. When the fix is ready this maintenance branch can be merged with both master and development.

The master branch needs to be tagged with the new version number and can then be deployed to production.