Very timely - I've been looking for a new way to handle
branches to recommend to clients/colleagues and this is the first
branch-per-feature concept I've ever seen that actually made
sense to me. Nice job!
One question:
> QA branch is created off master and gets all completed
> features merged into it; it is recreated every time a new
> feature becomes ready, or when a feature that was being
QA'd
> has been deemed not release-ready (so it gets recreated
> without that feature branch in it).
I can see why you would need to recreate the QA branch when a
feature gets pulled out (or whenever plans change otherwise), but why
would you need to recreate the whole branch when a new feature is
ready? Couldn't you just merge the feature into the QA branch
directly?
And one comment:
For the particular use case I'm thinking for this, I'd
actually consider a simplified version that leaves out the integration
branch and git rerere. The reason is, this would be for clients who
basically have a site they are happy with but are on a maintenance
plan, so (a) the "features" are often bugfixes and
relatively small additions to the site (not major changes) and
therefore very unlikely to have merge conflicts, and (b) some of the
clients have their own developers working on the site occasionally,
and I think the integration branch and git rerere concept might be too
complicated to explain to a large and diverse group of people.
Perhaps the first time a merge conflict and a "change of
release plans" event do arise at the same time I'd regret
that decision :) But otherwise seems like it might be a simpler way
to do this for certain use cases.
Very timely - I've been
Very timely - I've been looking for a new way to handle branches to recommend to clients/colleagues and this is the first branch-per-feature concept I've ever seen that actually made sense to me. Nice job!
One question:
> QA branch is created off master and gets all completed
> features merged into it; it is recreated every time a new
> feature becomes ready, or when a feature that was being QA'd
> has been deemed not release-ready (so it gets recreated
> without that feature branch in it).
I can see why you would need to recreate the QA branch when a feature gets pulled out (or whenever plans change otherwise), but why would you need to recreate the whole branch when a new feature is ready? Couldn't you just merge the feature into the QA branch directly?
And one comment:
For the particular use case I'm thinking for this, I'd actually consider a simplified version that leaves out the integration branch and git rerere. The reason is, this would be for clients who basically have a site they are happy with but are on a maintenance plan, so (a) the "features" are often bugfixes and relatively small additions to the site (not major changes) and therefore very unlikely to have merge conflicts, and (b) some of the clients have their own developers working on the site occasionally, and I think the integration branch and git rerere concept might be too complicated to explain to a large and diverse group of people.
Perhaps the first time a merge conflict and a "change of release plans" event do arise at the same time I'd regret that decision :) But otherwise seems like it might be a simpler way to do this for certain use cases.