Aegir development makes a heavy use of git branches to keep the main branch stable. We use feature branches to do most development work and have release branches to keep stable releases maintained while development happen on the main (and dev) branches.

Branch naming conventions

• master is always the main development branch. Think of it as CVS HEAD. When you commit there, you make everyone suffer, so unless you are confident your change needs to be in the mainline, you are likely to want to use feature branches (below).
• aegir-0.x are stable branch releases, where aegir is the subproject name (e.g. provision-0.4-alpha3, hostmaster-0.4). Once we hit 1.0, it's exactly the same thing without the 0.: branch is aegir-1 and tags are aegir-1.x. Commits to those branches should be first tested on the master branch (if possible) and then carefully tested there through alpha/beta/rc stages before a new tag is laid.
• development or "feature" branches must be prefixed with "dev-" and use the issue number (if available or relevant) and a short name. So for example, there could be work on a dev-12345-mybug branch or dev-dns branch for a larger feature (DNS, in that case) which doesn't fit in a single issue.

Development branches should be based of a known stable baseline as much as possible. For example, you can branch off the last alpha release if you want to be certain you have a sane environment (see this article for a thorough discussion on this practice). Since the master branch is usually fairly stable, you can usually keep that as a baseline, but keep in mind it will make merging with other dev branches more difficult as you will start from different baselines and therefore merge unrelated commits.

Tag naming convention

Every release is tagged with a aegir-x.y tag (e.g. aegir-0.4 or aegir-0.4-alpha15).

It is important that this naming convention be followed, particularly for release tags, as the tags are used to generate the tarballs published on http://files.aegirproject.org/. (See this script for details on how this works.) So if a tag named provision-0.4 is pushed, the provision-0.4.tgz file will be generated.

CVS and history

Deprecated and/or merged branches will be moved to an eventual "attic", a clone of the main repository that will keep all dead branches. We will cleanup every major release.

The CVS tags and branches are still accessible in git and will be kept there for posterity. They respect the traditional Drupal.org naming convention.