Release Management with Gitflow

Release Management with Gitflow


Clock follow gitflow but use '/' instead of '-' to group branch types and we encourage developers to push their branches to origin at least daily.

Long Version

Clock's branching and release methodology very closely follows the gitflow method. Our development falls into three broad project types: initial builds, phased updates and maintenance work, and it is important that our method works for all types. On a single project several concurrent features can be under development by one or more teams. Some clients are happy to agree a sprint and accept the delivered features as a release at the end of the sprint. Other clients change their priorities on a daily basis so features get dropped and added from a release at short notice. We are committed to the highest level of client satisfaction and ensuring a premium customer experience, so it's vital that our processes have the flexibility to ensure we can deliver on that commitment.

On top of gitflow we have our own in-house definitions and a slightly modified naming convention.

Main Branches

Repos will always have these branches:


This is what is in production. Before a site goes live for the first time this will be the most up to date staging release.


Receives all features during an active development phase of a project. This should be as stable as possible so that the team have an up to date and reliable base to work from. All tests and QA should pass on this branch so continuous integration is possible.

Single Commit Features

If there is a features or minor update that can be made in a single commit then it is acceptable to commit directly to develop but problems can arise if the feature takes longer than a day to complete. It is important your work is pushed to origin regularly to protect against loss, so as soon as it is suspected that a feature is going to take longer than expected, or is going to be a series of commits, then a branch should be created so the commits can be pushed to origin without risking pushing partial features to develop.

Feature Branches

New features should branch from develop, from a release branch or possibly even a hotfix if something is missed. It is important that you only merge branches that you want to incorporate into your feature so you do not introduce other unrelated features when your feature is merged in. It is normally safe to regularly merge up from the branch you originally branched from.

Naming Convention: feature/{feature-name}


git checkout -b feature/profile-page
git checkout -b feature/access-control

Unlike gitflow we recommend that developers push their feature branches to origin at least daily even when features are not complete.

git push origin feature/profile-page

git is distributed by design but at Clock we nearly always have a central origin, usually github. Pushing your work daily to origin, or at least pushing commits to a team member, prevents code loss when a developer goes AWOL, is out of reach or looses their laptop.

Bug Branches

Often a task is solely to fix a bug. These could be created as feature branches, but it feels wrong saying 'feature/fixing-wrongly-aligned-panel' so we have adopted the 'bug/' prefix for such cases. 'bug/badly-aligned-button'

Release Branches

In most cases release branches are branched from develop once an agreed amount of completeness is reached. Generally develop is not again merged into the release branch, but small changes may be merged from other feature branches if something is missed or a long time elapses between creation and deployment. Once deployed and all checks pass, the release should be merged back onto develop and master. As described in gitflow releases are versioned with major and minor at time of creation.

Naming Convention: release/{version}


git checkout -b release/1.2

Hotfix Branches

If the commits made to develop are not wanted in a release then a hotfix is required. Hotfixes are releases that resolve issues and add essential features outside of the planned release schedule. They should be branched from master and merged back to master then into develop and any pending release branches to prevent regression.

Naming Convention: hotfix/{version}


git checkout -b hotfix/1.2.1


Before any deployment the release or hotfix branch should be tagged with a version number. Clock follow the Semantic Versioning for all software versioning.

Deployment to testing for a stakeholder to check should be either an alpha or beta version with the tag: 1.48.0-alpha1, 1.48.0-beta1, 1.48.0-beta2. Alpha can be any partial feature that you want to simply show some progress of. Beta releases should pass some basic quality assurance and have the potential to become a release candidate.

Signing Tags

For production releases the release manager should use the -s option for git tag to verify that they are satisfied that all QA checks have been made and that the release is production ready.

git tag -s 1.48.0-rc1
git push --tags

The first version of a release to go on staging should be the first release candidate: 1.48.0-rc1 this should then increase, 1.48.0-rc2, 1.48.0-rc3, 1.48.0-rc4 until the release is deployed and signed off, at which point the last release candidate can be tagged as the final release.

git tag -s 1.48.0
git push --tags

Then merged back on to develop and master.

git checkout develop
git pull origin develop
git merge 1.48.0
git push origin develop
git checkout master
git pull origin master
git merge 1.48.0
git push origin master

Hotfixes should increase the patch version

git checkout hotfix/1.48.1
git tag -s 1.48.1-rc1
git push --tags

Pre-golive Releases

Before a project is publicly released, 0.x releases can be made using the same method as described above.

Smooth Operations

Even with an agreed method it can be very hard to keep all developers on the correct branch. Strong project leadership, good team communications and regular reviews of the 'git log' is required to ensure features are not lost and the team know where they should be committing and merging their work.

Release Manager

Good process goes a long way to ensure a slick development and release effort, but it is just as important to assign every project one person who is responsible for creating releases, arranging the deployment, communicating with the team and stakeholders, and then ensuring the merging down after deployment. A good release manager will keep the repo healthy and well ordered, keep the development team happy and well informed and give a premium experience to all stakeholder and customers.

Want to discuss a project?

Got a question? Want some more detail? We'd love to hear from you, contact Jason on +44 (0)1923 261166 or


26 May 2016

How to stop your customers' data being stolen

If we, as an industry, take anything from the data leaks at TalkTalk, British Gas and Morrisons, it should be that we must take every measure we can to secure customer data. Offering customers a more personalised experience means providing an environment where they are confident that the information they provide will be safe. Collecting and storing customer data and finding out more about your users is key to generating leads and gaining customer insight. But in the rush to get campaigns out the door and find affordable ways to create your digital products, ensuring third parties don’t risk your customers’ privacy and your reputations can be overlooked.

Screen Shot 2016-05-13 at 12.44.37.pngRead
16 May 2016

How to build, test, share and publish a javascript Hybrid mobile application using Cordova

Mobile Applications (Apps) are something every developer wants to create, however, not every developer wants to have to learn multiple languages to be able to create an App which works across different types of devices, such as Android and iOS. Learning Objective C (or Swift) and Java is probably enough to put most people off the idea of creating a cross-platform App. However, it’s possible to create one using technologies which most developers are familiar with. Good old HTML, CSS and JavaScript is all you need. Well, that and Apache Cordova, the mobile application development framework that allows you to build Apps for multiple platforms using a single code base.

26 April 2016

MongoDB Performance on ZFS and Linux

Here at Clock we love ZFS, and have been running it in production on our Linux file servers for several years. It provides us with numerous excellent features. With the recent release of Ubuntu Xenial 16.04 official support for ZFS is now here, and we are keen to integrate it fully into our next generation hosting stack.

Come and work for Clock

Clock is made up of bright, hard-working and talented people and we're always on the look out for more. You can browse the current jobs below or follow us @clock for the latest vacancies.

View Latest