Subject: Re: Branching strategies

From: Jakub Narebski <[email-masked]>
Date: Thu, 15 Sep 2011 04:07:03 -0700 (PDT)

robert mena <[email-masked]> writes:

> I have a project where I have to do a continuous integration, adding
> features/making changes on a daily basis.  Some changes are one liners
> with no functionality just, for example, textual changes or a new
> button.   Some are actual features or bug fixes.
> 
> So today my developers do their business and publish the changes in a
> beta site where the customer or the qa takes a look.  The problem is
> a standard one.  Sometimes features stay already developed (waiting
> for review) for a long time and other changes/features get approved
> first.
> 
> Since some of those can touch the same files how can I make this a
> little bit better (manageable)?
> 
> I am considering doing feature branches.   The customer requests to
> add feature A I open a bug tracking issue and create a branch 1276
> corresponding to the bug id.
> 
> In my simply view I'd have a master/live branch and every time I need
> to create a new branch I do it from here.  When the developer is happy
> he merges his branch with a beta branch where the Q&A/customer review
> is done.
> 
> When this review gets an OK he merges his feature branch with the live
> one, redo the tests and publish.
> 
> I'd really appreciate feedback for this specially for the weak points
> and known problems of my approach with alternatives :)

The "Version Control by Example" by Eric Sink, http://www.ericsink.com/vcbe/
contains chapter about workflows, including feature branch workflow.

Junio Hamano blog (the old version) included a few articles about
using feature-branch workflow too.

HTH.
-- 
Jakub Narębski