This topic covers conventions used for naming git branches during development of LabKey Server. Others developing new functionality in feature branches can benefit by following these practices.

Branches

At repository creation time, the primary development branch will be created:

• develop
  • Use this branch in the same way you may have used trunk in the past
  • Make this branch the default branch for the repository

Features and bug fixes

A new branch should be created for each story. Use an identical branch name in every repository involved in a story (often just one).

label = a short, unique description of the feature or bug

id = the issue ID or Scrumwise item ID related to the work

• fb_<label>_<id>
• fb_ stands for "feature branch"
• XX.Y_fb_<label>_<id>
• Features targeted for inclusion in a specific release (existing or future).

Other types of fixes

Other fixes, such as test fixes that have neither a spec number nor an issue number should still use the fb_ naming pattern.  In this case, however, you will likely just use fb_<label>, but be sure to coordinate with other team members to avoid conflicts.

Release

For each LabKey Server Stable release, a new branch will be created:

• releaseXX.Y-SNAPSHOT
• The primary beta release branch; related feature/bug-fix branches should be created from it
• XX is the major revision number
• Y is the minor revision number
• XX.Y_fb_<name>_<issue number>
  • For features and bug fixes developed against the specified release
    
• releaseXX.Y
• Final non-beta/patch release branch
• Accepted features and bug fixes are periodically merged from releaseXX.Y-snapshot
• Each patch release will be tagged (XX.Y.Z)
• Feature branches should never be merged directly to this branch. The should go through the SNAPSHOT branch and merged for a new patch release

Protected Branches

We have configured GitHub to disallow commits directly to develop, releaseXX.Y, and releaseXX.Y-SNAPSHOT branches. Feature Branch Workflow has more information on developing and merging features.

TeamCity

Following these naming conventions will ensure that branches are built and tested by TeamCity. If a branch contains changes that shouldn't or can't run on TeamCity for some reason, a descriptive but non-matching name should be used.