#git-flow

With git flow you create a 'feature' which when done will be merged in the main 'develop' branch from which it will be 'released' to the 'master'. The main line to code on is 'develop', the 'master' will only be merged to after a 'release' or 'hotfix'. The master should contain only released code.

We have found that this model helps us in downsizing commit (in your feature branch nobody depends on compileable state), easier reviewing changes for the same feature and decreasing the amount of 'pushpullpush' style pushes when working with a large team on the master.

There are tools to support this model for all os's (sourcetree, git flow command line extensions) which reduce the amount of stuff you have to type or supply a GUI. For clarity i will describe the actions required when using no tooling to make clear that no magic is involved.

Feature development got easier

Create a feature branch based on develop with a descriptive name and code away. Do realize that a feature branch should normally be at most a workdays work due to the fact that you are not integrating (with other code changes). When done it is an excellent moment for a code review before you finish your feature branch by merging it back into develop and deleting the now obsolete feature branch. This moment can also be used to 'cherry-pick' features to be included in the main development line.

Release management got easier

The process is straight forward and contains clear decisions. First you create a release branch with the version to be released as name. Now is the time to stabilize if required (last bug fixes, check minified code, js and css) and bump the version in your code files. Commit al this and generate your release deliverables. Now tag your your released commit, merge your release to master and merge it to develop. Delete the branch, your last commit is tagged.

Hotfixes got easier

Create a hotfix branch (1.0.1) based on your released version tag you wish to hotfix (1.0.0). Now follow the regular release process as described above.

Pittfalls

Multiple products in one git repo will lead to difficulty with versioning.

When the customer has his own staging env it can happen that you have to release a hotfix (1.0.1) after releasing a new version to the customers staging env (2.0.0). This will result in a nonexisting code version in the master.

it is not the golden solution for all project sizes; the release management part will feel clunky for one man jobs.