Inspired from A successful Git branching model there are more and more projects giving this approach a try…
Installation
I went for the original nvie/gitflow and installed it with brew on my mac:
$ brew install git-flow
Project Setup
Since most tools show master per default we decided to go with a minor tweak in the branch naming:
master->productiondevelopment->master
everything else is default.
The following recording shows the initial setup of the repository:
$ git flow init
Which branch should be used for bringing forth production releases?
- master
Branch name for production releases: [master] production
Which branch should be used for integration of the "next release"?
- master
Branch name for "next release" development: [master]
How to name your supporting branch prefixes?
Feature branches? [feature/]
Release branches? [release/]
Hotfix branches? [hotfix/]
Support branches? [support/]
Version tag prefix? []
Developing a regular feature
In a single developer project you’ll need no more than:
git flow feature start <BugId>
To start working on a feature. Time to do some coding, coding, coding, …
and finish it with:
git flow feature finish <BugId>
You feature will be merged into master, the feature branch deleted and your working copy switch to the updated master.
When working in a team you’ll probably need more commands like rebase, diff or publish which are well described in Feature.
Note: More sections will follow while working on this project…
Other conventions
For commit messages there is a lot of buzz like How to Write a Git Commit Message.
We mainly follow the Git developers Describe your changes well
- The first line of the commit message should be a short description (50 characters is the soft limit,…), and should skip the full stop.
- imperative mood like the Git developers themselves imperative-mood
- …
Note: For the first line we favour a hard limit of 72 characters - you can always use elipses at end if you use the bug title and the first line if too long