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.