Inspired from A successful Git branching model there are more and more projects giving this approach a try…
I went for the original nvie/gitflow and installed it with
brew on my mac:
$ brew install git-flow
Since most tools show
master per default we decided to go with a minor tweak in the branch naming:
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
When working in a team you’ll probably need more commands like
publish which are well described in Feature.
Note: More sections will follow while working on this project…
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