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