Branching models for use with version control tools (git and git-flow)

This post is a high-level overview of the subject, with a little discussion.

A version control (or source code control) tool helps you manage versions or branches of software (or whatever: code, text, images, ….)  For example, git is a version control tool.

But on a project (whether with one developer or a team), you also need ‘business processes’ for using the version control tool.  These business processes help you and the rest of the team cooperate effectively.  Such a ‘business process’ comprises:

  • a branching model
  • a set of standard procedures for using the version control tool (how members behave)
  • a product roadmap or feature list that drives development

A branching model describes the branch artifacts that the project will use, and guidelines for creating and merging branches.  Examples:

Comparison of the examples

The git-flow branching model only has two long-lived branches:

  • ‘master’
  • ‘develop’.

The Qt branching model as three long-lived branches:

  • ‘dev’ (alpha)
  • ‘stable’ (beta)
  • ‘release’ (corresponds to git-flow master)

The traditional terms are alpha, beta, and release:

  •  Alpha: so buggy that usually only developers will want to work with it.
  • Beta: nearing release, feature frozen, and usable by early-adopters, but probably still having some bugs, and not supported to customers.
  • Release: published, and supported to customers.

The branching models both have other temporary branches, for releases and bug fixes (although they are not shown in the Qt diagram.)

The Qt branching model is a little fuzzy about how bug fixes are put back in development: it says they are ‘periodically’ moved back to development, i.e. from most frozen to least frozen.  The git-flow branching model shows that a bug fix always goes to both long-lived branches (master and develop.)

Both branching models also have mostly unstated (implicit) rules for the merging.  Rules about quality, size, frequency, etc.

Qt discusses that their project only supports the latest release.  You can infer the same from the git-flow diagram, since there are no long-lived, other branches from ‘master’.  In other words, to support an ancient release version that had diverged sufficiently from the current release so that a fix could not be made without conflict, you might need to create other branches from ‘master.’  (This might be a so-called ‘support’ branch, which is alluded to, but not fully described, in the git-flow documentation.)

The Qt branching model doesn’t seem to have a tool, instead you must know and remember the processes.  The git-flow branching model has a tool:

git-flow the tool

git-flow is yet another tool.  It extends git.  It enforces it’s branching model.  It is ‘high-level’, on top of git.

Another, ‘only a long-lived master’ branching model

Some of the criticism of git-flow seems to say that only one long-lived branch (master) is really needed.

Anecdotally, large projects (such as Qt) seem to use many long-lived branches.

While it may be true that only one long-lived branch is necessary, it may also be true that a tool such as git-flow, which hides some of the details of the git commands needed to enact the business processes, may be helpful.  In other words, I don’t care how many long-lived branches a tool or business process uses, as long as there is not a ‘model clash’ with my mental model.   I want to think less about version control, and more about the application.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s