Using Git for an Effective Development Workflow

Overview The following is an outline of the branching, merging, and workflow conventions that can help development teams manage parallel feature development and release management. This workflow style is taken directly from http://nvie.com/posts/a­successful-git­branching­model/ Please visit that site to read the full­ length post on the details of this method.

Primary Branches:
There are two public branches which have an infinite life:

master: commits to this branch should be comprised only of snapshots of the project for releases. Ultimately, there will be few commits in this branch. Most commits in master will be tagged as versions. It is possible that alpha and beta versions may be tagged in master as well ­ depending on the situation

develop: the main branch where the most commits will reside. develop represents the latest complete build of the working system for the next release. Commits directly onto develop may occur when fixing minor bugs or issues unrelated to a feature. Instead, they should be occur as merge commits from features, releases, or hot­fixes. (see graphic) Continuous integration will be configured to pull and build from develop.

Secondary Branches:
Public secondary branches have a finite life and may be used to support feature development, releases, or hot­fixes. Most secondary branches should be kept private (local), unless there is a coordinated agreement between developers that will be working on the feature together. Since secondary branches eventually will be deleted, it is risky to publish them upstream without declaring who should be manipulating the branch.

Conventions and Best Practices:
Almost all merges should be executed as a “no fast­forward” with the ­­no­ff switch. This ensures that history of branching and merges remains visible. Rebase your commits locally to clean up, squash, split, reword etc. prior to merging into develop Secondary branches should be named according to the following conventions for consistency:

Feature branches: feature­_____

Hot­fix branches: hotfix­_____

Release branches: release­_____

Long­term feature branches: epic­_____