branch names

Robert Buck rbuck at redhat.com
Thu Jul 21 16:23:58 UTC 2011


Hi Folks,

Related to this thread and an IRC discussion, when folks have a moment, 
please take a gander at the wiki page I added. Please provide some feed 
back there as wiki comments. If you want, you can also reach me on the 
RHQ IRC.

   
http://rhq-project.org/display/RHQ/Git+Branch+and+Tag+Naming%2C+and+Workflow

Thanks
Bob

On 07/20/2011 12:46 PM, Robert Buck wrote:
> 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
> _______________________________________________
> 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