Topic Branching

Within the Version Control System, topic branches are created from the default branch to represent individual change requests (Jira issues). The branches are short-lived and merged back into the default branch when the task is done. An alternative to Topic Branching ("Git Flow") is Trunk Based Development(TBD)


See also 

    • Make your integration branch the default branch in Git, even if its not named "master". 
      • The default branch should be the branch that receives the most pull requests. 
    • For version branches, a good technique is to use "master" as folder and couch each version as a subfolder. 
      • master/ABC_1.2, master/ABC_2.0
  • Use a short-lived task branch (aka feature branch) to isolate work before it is merged into the integration branch.
    • A task branch corresponds to a JIRA issue, and can be named like the issue (ABC-123). 
      • A task is an agile story and should take less than sixteen work hours to dev-complete. 
    • It is first used locally, and then committed to the shared repository (Bitbucket) for peer review, testing, and merging.
  • When ready for a new version, merge the integration branch into master, to isolate the changes being made for a each version.

Commit often, and before merging the task branch back into the integration banch, squash the commits

  • For audit purposes, ideally, there is one commit per agile story / task / JIRA issue. 

See Also

Please submit feedback to the DreamOps Success Group