Git Branching Model

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

References:

• A successful Git branching model
• github flow
• Branching workflows
• Distributed workflows