We recommend the following naming schema for git branches which are pushed to publicly accessible locations (local branches do, of course, not have to conform to these recommendations):
master
TODO
VERSION
For branches in which released versions are maintained. Examples of VERSION are 0.8, 0.22 and 1.0.
Important
Branches of this kind should be deleted (locally and remotely) once their contents has been verified and merged into the respective parent branch (usually master or a VERSION maintenance branch).
bug-ISSUE-NUMBER
For branches in which fixes to particular known bugs are being developed. ISSUE-NUMBER should be the number of the issue tracking the bug in the issue tracker.
These branches will participate in merge tests conducted by the continuous integration server.
feature-ISSUE-NUMBER
For branches in which new features are being developed. ISSUE-NUMBER should be the number of the issue tracking the feature in the issue tracker.
These branches will participate in merge tests conducted by the continuous integration server.
feature-NAME
For branches in which new features are being developed when there is no corresponding issue in the issue tracker.
These branches will participate in merge tests conducted by the continuous integration server.
Note
It is recommended to track new features in the issues tracker and use the previously described feature-ISSUE-NUMBER naming schema.
wip-NAME
For branches which just store some unfinished and/or broken changes not related to a particular bug or new feature. This kind of branch is useful for storing unfinished work without triggering merge test on the continuous integration server.
These branches will not participate in merge tests conducted by the continuous integration server.
Important
Tag names must not clash with branch names. Therefore we recommend release-VERSION instead of just VERSION for tag names.
release-VERSION
For tags which mark the point in history at which the release branch named VERSION diverged from the mainline history.