Re: [boost] [git] neglected aspects

Subject: Re: [boost] [git] neglected aspects
From: Daniel James (dnljms_at_[hidden])
Date: 2012-02-08 14:30:02

On 8 February 2012 14:37, Julian Gonggrijp <j.gonggrijp_at_[hidden]> wrote:
>
> This might have been mentioned before, but gitflow seems to be ideal.
> See [5] for an explanation of the branching model and [6] for an
> optional tool which automates workflows that adopt the model.

The problem that we face with something like gitflow is testing. We
only have the infrastructure for testing two branches so we can't
adequately test feature branches. We really do need to test on a wide
variety of platforms as early as possible. But we wouldn't want to
merge half done features into the develop branch just to get testing
(this is one of the biggest problems we have at the moment, changes
are often in trunk for some time before they're merged into release,
if at all).

A possible solution would be to use the 'develop' branch as the
equivalent of our current release branch (I'm not sure how to branch
for release, we might have to do without and just restrict additions
to develop as we currently do, at least at first) and add another
'testing' branch. This would branch from develop, and feature branches
would be merged into it for testing. Once testing has shown the
feature branch seems to be release worthy, it would be merged into
develop. The testing branch would never be merged into anything (its
history would be very messy). We would probably create a new testing
branch regularly (once per release cycle?) so that neglected features
would be dropped.

Or maybe, rather than being a traditional branch, the test repo could
be created by a script which merges in active feature branches. It'd
have to deal with conflicts though, maybe just keeping track of
commits that are known to be good and sticking with them when a
conflict is found. But something like that could be developed later -
especially after having some experience of how the process works.

This testing mechanism would be fairly separate from the main flow
structure so it could be provided by an additional tool to gitflow.
Hopefully wouldn't be too hard to develop. Does that make any sense? I
know it isn't ideal, but it seems plausible given our current
infrastructure. And we could work on improving it as we go.