Re: Branching strategies

From: gitlist <gitlist@myword.co.uk>
Date: Sep 19, 2011, 18:51 UTC
Message-ID: <4E778F15.9050705@myword.co.uk>
In-Reply-To: <CAH5451kn5WD4+S3_SGMarGyoUs6NA6Xvz9Pb8Wdpt9v0nY+Uow@mail.gmail.com>

On 10/09/2011 02:18, Andrew Ardill wrote:

Show 7 quoted lines

> On 10 September 2011 09:01, robert mena<robert.mena@gmail.com>  wrote:
>> Hi,
>>
>>  <snip>
>> Since some of those can touch the same files how can I make this a
>> little bit better (manageable)?
>>

Show 6 quoted lines

> A very interesting read is
> http://nvie.com/posts/a-successful-git-branching-model/
>
> It may not be perfect for you, however it does discuss some very
> interesting issues, particularly how workflow is just as important as
> the branching model.

I came across the nvie post some time and it was very useful, but it doesn't address handling of feature branches, especially where there is overlap.

I have a website where people can register. They can also buy things. If they haven't registered when they come to checkout, the checkout process includes registration. Users can also create "sponsorship" pages where they ask friends to sponsor them in a marathon etc. If someone setting up a sponsorship page is not already registered, it's included in the process.

So there are three strands (to avoid using the word "branch") - registration, buying, and sponsorship - which end up affecting the same bits of code. Registration was done a year ago but recently needed updating; buying was started some months ago but got held up; sponsorship started recently, has been completed, and has "overtaken" buying.

How should I use branches in this scenario? Or if I've got the concept wrong, how should I change my workflow?

Thanks

Roddie Grant