branch names

Robert Buck rbuck at redhat.com
Wed Jul 20 16:46:05 UTC 2011


The topic of branches needs to take into account the overall workflow, 
and its relationship to tags. I've worked through this with several 
development groups at other organizations and here is the overall 
approach that was uniformly adopted.

With that, I hope this will foster some good debate:

TAGS

Tag Names

   Tags are created when important milestones in a development project 
are achieved; important events may include, but are not limited to:

   * build number
   * alpha's
   * beta's
   * release candidate
   * release

   Tag naming follows these conventions:

   * v1.2.3 - for release tags
   * b24455 - for build tags and all interim distributions leading to a 
release

   Following these conventions allows developers to search, using git, 
for tags following particular patterns.

BRANCHES

When to Branch

   Branch only when necessary:

   * when concurrent lines of development occur across releases
   * when larger, potentially volatile, changes are created in isolation 
to prevent breaking master builds

Model

   When branching, use a branch-early, merge-often, approach. This helps 
manage risk; it reduces the likelihood of a large complex merge by 
amortizing the cost over a series of smaller simpler merges. Merge daily 
if possible.

Master Branch

   Master represents the main line of development; master may be 
unstable, but with that said developers should strive to never break the 
builds. Development primarily occurs on master with occasional feature 
branches feeding larger units of work to it.

Feature Branches

   Feature branches represent larger units of work that, as a unit, may 
possibly be rolled back atomically. Feature branch histories are 
squashed prior to commit to master so they may be rolled back from 
master in the event a feature needs to be removed from a release.

   The naming convention for feature branches follows:

   * feature/fancywidget


   Following these conventions allows developers to search, using git, 
for branches following particular patterns:

   git show-branch "maint/*"
   git show-branch "bug/*"

   Merge histories may also be searched for which bugs have been merged 
into a branch using this approach.

Maintenance Branches

   There is no such thing as a release branch; there is only 
maintenance. Once a release is cut and its tag made, no other activity 
related to the release occurs unless needed. In other words,

   The naming convention for maintenance branches follows:

   * maint/1.2.3

   Maintenance branches are completely unnecessary unless multiple 
versions face active development; then in this case it exists and serves 
as an accumulator for accepted patches, a subset of patches that feed 
into master.

Bug Branches

   Bugs may be serviced through patch files or branches, depending upon 
how complex the fix is. The naming convention for bug branches follows:

   * bug/12345

   If possible, use patch files instead of branches. N.B. caveat that 
bug branches are only applicable to a single line of development, a 
single version.

User Branches

   User branches follow this naming convention:

   * user/topic

   , where user is kerberos username, and topic unambiguously identifies 
scope of work.


-Bob

On 07/19/2011 06:51 PM, Charles Crouch wrote:
> (3:01:33 PM) rbuck: mazz, jsanda: please check out rbuck/rpctimeout, i changed two files to add query-string based configurable timeout support
> (3:02:07 PM) mazz: you couldn't just put it in origin/ ? I see we have a difficult child :)
> (3:03:43 PM) rbuck: here's the ref: origin/rbuck/rpctimeout
> (3:06:36 PM) rbuck: its simply a hierarchical name
> (3:07:04 PM) rbuck: that way i can quickly and easily search, in git, for all branches of specified patterns
> (3:08:56 PM) rbuck: then you can do things like this:     git show-branch "rbuck/*"       and see what branches exist, and what activity has occurred recently
>
> Besides our release branches we dont have a strong naming convention for branches holding long running features/short running features/one-off fixes/branches worked on by multiple people etc:
>
> http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=heads
>
>
> Bob/Mazz/all,
> Do you have suggestions for a naming convention that would consistently?
>
> Cheers
> Charles
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/rhq-devel



More information about the rhq-devel mailing list