Skip to content

Development strategy

Munen Alain M. Lafon edited this page Jan 12, 2014 · 1 revision

The development strategy is based on the article http://nvie.com/posts/a-successful-git-branching-model, please have also a look at the Deployment Workflow.

The following wiki page is a summary for quick access, but the linked article should be read for a full understanding anyway.

In contrast to the article, the develop branch is called integration, because development happens in feature branches and those are integrated into the integration branch before releasing.

master branch

The branch origin/master is the main branch where the source code of HEAD always reflects a production-ready state.

integration branch

The branch origin/integration is the main branch where the source code of HEAD always reflects a state with the latest delivered development changes for the next release. To track the branch after checking out the project use:

git branch --track integration origin/integration

In general no development happens directly on the integration branch, except fixing specs and updating the README and documentation.

feature branch

  • Branch off from: integration
  • Merge back into: integration
  • Branch naming convention: feature/<storyid>/<short-dasherized-identifier>

Create a feature branch:

$ git checkout -b feature/123456/view-company-video integration

Incorporate a finished feature on integration:

$ git checkout integration
$ git merge --no-ff feature/123456/view-company-video
$ git branch -d feature/123456/view-company-video
$ git push origin integration
$ git push origin :feature/123456/view-company-video

hotfix branch

  • Branch off from: master
  • Merge back into: integration and master
  • Branch naming convention: hotfix/<major.minor.patch>
  • Tag naming convention: v<major.minor.patch>
  • Version number must adhere to semantic versioning

Hotfix branches are very much like release branches in that they are also meant to prepare for a new production release, albeit unplanned. They arise from the necessity to act immediately upon an undesired state of a live production version. 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.

Since a hotfix does not add any new features, it has the same major and minor version as the previous release version and it MUST increase the patch version.

Create the hotfix branch:

$ git checkout -b hotfix/1.2.1 master

Finish a hotfix branch:

$ git checkout master
$ git merge --no-ff hotfix/1.2.1
$ git tag -a v1.2.1
$ git checkout integration
$ git merge --no-ff hotfix/1.2.1
$ git branch -d hotfix/1.2.1