On Wed, Jul 22, 2009 at 5:06 AM, Tekkub<[email protected]> wrote: > I think you missed a step in the process I outlined... you never touch > master unless you are deploying to production, so there's never a reason to > freeze anything.
Well... ... > The key to the whole workflow is that "master" is what is live on the > server. Everything after that is in a topic branch until it is merged into > master and deployed. You never leave undeployed commits in master. The local topic branches are going to be merged into the master at some point. How is merging of completed local topic branches timed and coordinated in your workflow? Such merges obviously cannot be done while a recent branch on the staging server is being tested and debugged and is pending a merge back to the master for production. This amounts to freezing out new merges to the master during this time. If you are suggesting that projects should be managed completely in topic branches until release time approaches, how are all the completed projects going to be tested together before then? I certainly don't want to wait until release is imminent to discover that projects A and B don't play well together. Certainly a strength of Git is that individuals can work on projects and share their work in local branches. But as each project is completed, it seems to me wise and prudent to merge it into the developing code base for the release for which it is intended, which may be some time away. Then nightly builds and testing can easily be set up to run on such a branch (call it "master" or anything else), QA can let their imagination run wild on it, etc., etc. -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 -~----------~----~----~----~------~----~------~--~---
