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)

Notes

• Include Issue IDs in Commit Logs for traceability.
• Topic branch for each issue
• Development environment for each issue

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

• Git Branching - Branching Workflows (git-scm.com)
• Git Flow vs. Trunk Based Development (www.topal.com)
• Trunk Based Development