On Jun 2, 3:39 am, Tekkub <[email protected]> wrote:
> Here's how I would approach this. Never work in master or release, only
> perform merges in those branches. Never merge release into master. Instead
> do all your work in topic branches branched off of master (never off of
> release). When they're ready to test, merge them into release. When
> they've been tested and are ready to be pushed out, merge the topic branch
> into master.
> I'm assuming, of course, that "release" is a
> staging branch used to testing, not a branch that represents your
> released versions (you might want to name it staging instead to make
> this clear).
No, the release branch is in fact the branch that will be used to
build an imminent release. Most changes made in the release branch
must be propagated to the master (which is the main branch that will
be used for future releases). But some changes must be restricted to
the release branch.
-P.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"GitHub" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/github?hl=en
-~----------~----~----~----~------~----~------~--~---
