Git branching for projects

Last updated on
27 July 2016

Currently applies to Customizations, DrupalCI: Test Runner and Bluecheese.

Branching for’s custom projects follows Gitflow, omitting release branches and tags.

  • Master is the default branch in the repository, following Drupal's contrib versioning. For example, 7.x-2.x or 7.x-3.x or production.
  • Develop is dev.
  • Features are {issue number}-{short-description}, for example 2182993-api-breadcrumb-space.
  • Hotfixes may be done on the Master branch directly.

Sample gitflow image
Release branches are omitted because our deployment is continuous. Deployments are batched by merging multiple Features to Develop, then merging Develop to Master.

Feature branching

Features should usually be branched from dev; be sure to pull first. If a feature depends on another in-progress feature, it can be branched from that feature.

Straightforward commits, such as fixing notices, or text fixes, may be done directly on dev. dev should always be deployable to production.

All features should have issues, with limited exclusions for Drupal Association business, e.g.:

  • Adding 3rd party integration tags, such as Optimizely.
  • Ad placements.
  • Association-specific pages, such as Supporter Programs.

Contributing as a non-committer

Please post patches as usual. Work from the dev branch.