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