Re: Branching strategies
- From
Jakub Narebski <jnareb@gmail.com>
- Date
- Sep 15, 2011, 11:07 UTC
- Message-ID
- <m3ty8errkd.fsf@localhost.localdomain>
- In-Reply-To
- <CAAZ43xaFzJWzPsqhP0QDRTP0Ea-dMpCpr1vDiujFFn94j+SRCQ@mail.gmail.com>
robert mena <robert.mena@gmail.com> writes:
Show 28 quoted lines
> 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