Project

General

Profile

Git Flow Workflow and Branching Model

We would like to keep git branching model for enstore development similar to one we have now in CVS.
Currently enstore CVS trunk contains 'pristine' code where code committed after code review and tagged as 'production' time to time.
With little or no exception, the 'production' tag follows the tip of the trunk. There are few branches used for major features development which later merged into trunk.

Git vcs supports both branches and tags. But it is very strongly suggested elsewhere that git branches must not be re-tagged as it creates ambiguity. Hence we shall implement differently re-tagging of "production" code we do now in cvs: production branch shall become a separate branch.

The article [1] "A successful Git branching model" provides description of workflow model used with git and has charts to visualize workflow and native git commands. This workflow model is used by several projects and there is implementation of this framework called 'git flow' [2]. Git flow framework "extends" git, simplifies and scripts all operations with central repository as a few [=two] commands corresponding to branching model. Git Flow Cheat Sheet [3] summarizes commands and branch chart. Someone can mix 'native' git commands with extensions provided by git flow when operating branches.
Please have a look on these three short documents to get started.

Git flow branching model generally fits our current branching model where we have single branch with production code and tags on this branch corresponding to code releases.
The difference with the model we use now: we split the trunk into two branches: one "development" branch where code committed by developers after review, and "production" branch, where only production code is kept.
This model adds several branches:
  • develop
  • release branch (transient)
  • production
  • hotfix (transient)
  • feature branches (semi-transient)
  • support branches (if needed)

Developers work on "feature" branches and commit code to 'development' branch when the code is approved during review.
Gatekeeper builds the release rpm code and keeps small modifications on "release" branch. When release is done, code is committed to "production" branch and tagged.
Developers take code from "production" to "hotfix" branch for emergency code fixes.

To illustrate how it works, after setting things up, the developer does:

 git flow feature start 3830-test-feature-1-for-gitflow
-- the code is extracted from git central repository for you
-- work on code
-- make patches, submit for review
git flow feature finish 3830-test-feature-1-for-gitflow
-- the code is committed to the branch develop on central repository, like this:
https://cdcvs.fnal.gov/redmine/projects/enstore-git-test/repository/show?rev=feature%2F3830-test-feature-1-for-gitflow

Similarly, to do hotfix:

git flow release start ENSTORE_RPM_3_2_1_0
-- the code is extracted from git central repository for you
-- work on code
-- make patches, submit for review
git flow release finish ENSTORE_RPM_3_2_1_0
-- code committed to the branch develop on central repository>>

and so forth.

Some workflow steps require to commit code to two branches, like hotfix shall commit to production and develop branches. The framework does it for you, you just tell "start" and "finish."

We will use this branching model described at [1] with the following change: we call "master" branch as "production" to better reflect its purpose - it is one of configuration choices in git flow framework.

Mapping to our current model:

Branches:
production - production version of enstore. There is "tag" for each release.
In our current model - this is 'production' tag in cvs trunk with tags related to releases.

develop - in our cvs model this is the head of our trunk in cvs
'pristine' code which passed through inspection and approved with "ship it!" .

release branches - this branch is created for release Gatekeeper when he works to build rpm.

hotfixes - hot fixes for emergency issues in production

feature branches - each developer has one [or few] for current projects / reviews.

References

[1] Vincent Driessen, "A successful Git branching model." Substitute "master" branch by "production" when reading.
http://nvie.com/posts/a-successful-git-branching-model/

[2] git flow repository, documentation, getting started:
https://github.com/nvie/gitflow

[3] Git flow cheat sheet
http://danielkummer.github.io/git-flow-cheatsheet/

[4] External Example: Git Flow tutorial
Step by step instructions from other project diaspora which uses gitflow. Webpage has concrete tutorial with commands to use.
https://github.com/diaspora/diaspora/wiki/Git-Workflow
http://wiki.diasporafoundation.org/Git_Workflow

[5] We follow [4] with Enstore Gitflow Example: Enstore Git Flow Tutorial