15 December 2015


Above digram illustrates the git branching model from a release manager's perspective. Basically,

  1. The "master" branch is always stable (it is not necessary, but helps to understand the topology).
  2. A release branches off from the master for release development.
  3. Code changes are merged back (git merge --no-ff) when development is finished.
    • NOTE: Once a branch diverges from the master branch (i.e. it is no longer the "current" release), code changes are no longer merged back. For example:
      • rel-2.6 code is not back-ported to master once rel-2.6 is delivered and rel-3.0 is cut.
      • If there is a rel-2.5.x branch, its code is merged to rel-2.5 but not master.
  4. The release branch is left open for bug fixes only.
  5. Bug fixes go into the release branch and cherry-pick into all other applicable branches.
    • Master branch does not cherry-pick bug fixes, as it will get the fixes eventually by merging currently developing release branch later.
  6. A sub-release branches off the release branch in a similar way if new features are needed after the delivery of that release.

Naming convention:

  • Branches
    • Release branches: rel-<release number>. For example: rel-2.5, rel-2.0.1
    • Feature branches: fid-<feature id>. For example: fid-14894
    • Bug branches: bug-<ticket number>.
  • Tags
    • Release tags: tag-rel<release number>. Example: tag-rel2.5
    • Daily build/smoke test tags: tag-<release number>-<build number>. Example: tag-2.5-b85


blog comments powered by Disqus