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!
> 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
> 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
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.
Meer informatie over tekstopmaak