Branching strategies

Branching strategies

[robert mena]

Hi,

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 :)

Regards.

Re: Branching strategies

[Andrew Ardill]

On 10 September 2011 09:01, robert mena <robert.mena@gmail.com> wrote:
> Hi,
>
> 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 :)
>
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.

Another interesting read is the maintainer's notes from the git
project. The branching strategy is a little different then the
previous one, and will perhaps give you a better understanding of the
practicalities of such a strategy. They normally can be found at
https://git.wiki.kernel.org/index.php/MaintNotes but kernel.org is
down at the moment so try
http://code.google.com/p/git-mirror/source/browse/MaintNotes?name=todo
You can also look at
http://git-blame.blogspot.com/p/note-from-maintainer.html and in the
source repository at Documentation/howto/maintain-git.txt

Hope that helps a little.

Regards,
Andrew

Re: Branching strategies

[Jakub Narebski]

robert mena <robert.mena@gmail.com> 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

Re: Branching strategies

[gitlist]

On 10/09/2011 02:18, Andrew Ardill wrote:
> 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)?
>>

> 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

Re: Branching strategies

[Andrew Ardill]

On 20 September 2011 04:51, gitlist <gitlist@myword.co.uk> wrote:
>> 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

The concept of 'feature branches' apply primarily to development.They
allow you to build individual features for your system independently
of one another, and concurrently. Further, they provide a history of
commits that detail the effort that went in to creating that feature.

Once the feature is completed however, typically it will get merged
with a given release of the system. If further work is to be done on
that feature, either a new feature branch is created for the
'improvement', or a similar hot-fix/bug-fix branch is created. When
that work is done it gets merged either back on to the same release or
into a future release.

These feature branches do not host the separate functionality of the
system, but instead reveal the history of their development. I have
not heard of any intelligent way to use just an SCM to partition and
keep separate the different functional aspects of a system; developing
modules is generally achieved by writing modular code.

If you do have a number of modules you can track each of them
individually. Write version-dependencies into the modules, and you can
develop on them individually, updating them to depend on the latest
version as appropriate.

If you are not using well separated modules, and the development of
each 'thread' affects the same 'core' files, you need to migrate
changes to these core files between threads when appropriate. For
example, if you are working on the sponsorship thread, and develop a
paypal integration that you now want to include in the buying thread
(and can't continue developing it until you do), you should identify
the commits that entail that change and merge them into the buying
thread branch. Better than retrospectively trying to dig out features
and bug-fixes, however, is ensuring a clean separation of thread code
and core code. Thankfully, since git has such good merging ability,
you can often merge a feature branch which is miles behind the latest
release and it will slot in flawlessly.

There are many different aspects to this sort of work, but the best
thing to do is to keep the future in mind, and try to do things that
will make life easier down the track. The great thing about git is
that it offers many tools that make things easier later on even when
you didn't plan for them - but that is no excuse for poor planning!

Hope that helps somewhat,
Andrew