Personally speaking, I don't make a branch for every release, just for every "logical changeset". Think in terms of an issue tracker, make a branch for every ticket. Branch off at the point the issue originates. If it's a bugfix in a release, branch off at that release's tag. If it's something new, branch off of master. Never work directly in master (and "staged" or "edge"), instead only perform merges into those branches. If you keep your branches "atomic" it's very easy to pick and choose what things you want to pull into master without need for cherrypicking or rebasing things you've already pushed. --tek
On Fri, Oct 17, 2008 at 8:13 AM, Wilhelm <[EMAIL PROTECTED]> wrote: > > Thanks, > > I see the benefit of having local branches and use it already, but I > was particularly interested in the latter part. Should only the > maintainer commit to master, so that it's kept atomic and pristine? > How do you decide how many major release branches to have? > > Wil > > On Oct 16, 12:08 am, Darren Duncan <[EMAIL PROTECTED]> wrote: > > Wilhelm wrote: > > > I'm rather new to github, so I was wondering what a goodbranching > > >strategywould be? Right now, I cut a branch every time there's a new > > > release, so that I can keep working features on master, and then > > > emergency bug fixes on the cut branch. > > > > > However, this assumes a fixed release schedule. Sometimes, it seems > > > like we want to push features/bug fixes out midweek. My current > > >branchingstrategyfills up branch names, and makes it difficult to > > > deploy between release schedules. > > > > > I was told an alternativebranchingstrategywould be to use one > > > branch called 'edge', and merge or cherry pick commits from edge to > > > master, and then deploy to production off of master. Then tag every > > > deploy to production w/ its version number. > > > > > What is a known goodbranchingstrategies? Thanks. > > > > One goodstrategyis to add a branch every time you are going to make a > > non-trivial change, such as a change that would be saved as a series of > multiple > > commits in the middle of which you don't assume that the current state is > > stable. This is especially true if there's a reasonable chance that > while you > > are working on one change, you may have to interrupt it to work on some > separate > > change that needs to deploy first, or alternately if your muse hits you > and you > > want to change gears for awhile, and then go back. Have a branch for > each > > development idea you want to follow, especially if you consider it an > > experiment, but its often good even if you don't consider it an > experiment. > > Hope that helps. Also, having a maintenance branch per major or > non-trivial > > release is good too, especially if you have users. -- Darren Duncan > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
