I think that the best way to go is to have a staging server which contains the most up to date version of the master branch. (updated automatically every 15 minutes or less).
No fixes should be deployed to the release server between iterations, except critical ones (deploying only the involved files). At the end of an iteration, the master branch can be deployed as-is to the release server. Imho having (and keeping up to date) too many branches just causes confusion and it can be time consuming dealing with all the possible conflicts, etc that may appear. Just my 2 cents :) On Wed, Jul 22, 2009 at 8:16 AM, Peter Shenkin <[email protected]> wrote: > > On Wed, Jul 22, 2009 at 12:46 AM, Tekkub<[email protected]> wrote: > > Staging would be the server you deploy to to test things... somewhere in > the > > middle between development and production. > > Thanks.... > > But then why wouldn't you deploy from the staging branch? If you plan > to deploy from the master, wouldn't you have to freeze merges into the > master while the testing is going on? > > Once you have feature freeze, it seems more logical to define a branch > to use for testing, bug fixing, and release (deployment), freeing up > the master for the merging of projects to be released later. > > -P. > > > > -- Joan Crawford<http://www.brainyquote.com/quotes/authors/j/joan_crawford.html> - "I, Joan Crawford, I believe in the dollar. Everything I earn, I spend." --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
