Skip to content

CKB GitFlow

Overview

A release branch can be short- or long-lived. In either case, the release branch reflects the set of changes that are intended to go into the production release process. Once a production release has been completed the release branch is merged into the main branch and can be deleted. Thus the main branch should always be a reflection of existing production code.

For CKB the temporal nature of release branches will be tied to the length of a Sprint (which varies widely in our case). In other words, we expect a production release for each Sprint so each will have a release branch created and associated with it. Release branches are created either at the beginning of a Sprint from the main branch or from the current Sprint's release branch if future work has begun prior to a production release. Developers will create feature/bug fix branches from the release branches that their work will be merged into. Once the work has been completed a Pull Request will be created and reviewed by another developer before being allowed to be merged (and deleted post-merge).

Branch Naming

  • Sprint branches: sprint/{sprint #}
  • Bugfix/Task: sprint/{sprint #}/{JIRA #}
  • Feature: feature/{feature name}

S.O.P.

For each Sprint the following tasks are required:

  1. Create release branch.

    1. If previous Sprint merge tasks are complete: create from main branch

    2. If previous Sprint merge tasks are NOT complete: create from previous Sprint release branch

  2. Merge release branch

    1. Post-production release the release branch is merged into main and deleted

    2. If future Sprints release branches have been created then merge main into existing release branches

  3. Branch cleanup

    1. Review and delete any branches that are no longer required (created and assign tasks in the Sprint to developers if needed)

Gitflow Model

Development

Develop features/bug fixes off the release branch associated with the Sprint the work will be released in Create PRs back to the same release branch Have a Jenkins CI build point to all existing release branches Have a Jenkins CI build point to the main branch

Release

Pre-Release

  • Deploy tags created on commits in release candidate branch

Post-Release

  • Create PR for merging release candidate branch back to develop and master
  • Create PR for merging release candidate branch into future release branches
  • Review and prune old/unnecessary branches

Source articles

  1. A successful Git branching model
  2. Atlassian Gitflow
  3. Best branching strategies
  4. Trunk based development
  5. Computational Sciences Confluence - Source-Control Branching Model