On Mon, Jul 20, 2009 at 5:50 PM, Ken<[email protected]> wrote: > Now that I am close to deploying version 1.0 to production I have been > trying to figure out an appropriate workflow. Would the following > work: > > a. Make any final changes and push the changes to the local git > repository (branch = master). > b. Push the changes to github with this command: "git push origin > master" > c. Use Capistrano to deploy changes to the production server using > github as the the repository.. > d. Create a new branch called "release2" in the local git > repository. > e. Continue development of Release 2.0 code in the release2 branch. > f. If a bug fix is required to version 1 code, commit the changes to > the master branch in the local git repository, do a "git push origin > master" and deploy from the github master branch to production. > Also, > merge the changes into the release2 branch. > g. When release 2 is done, merge the release2 branch into the master > branch and deploy from master. > > Or, is there a better way to do what needs to be done? > > I would sincerely appreciate any ideas or suggestions.
That sounds pretty good. At GitHub we take it one step further: instead of creating branches for each "release," we create branches for each feature. "New User ACL," "Issues RSS Feed," etc. Then we merge the feature into master when it's ready to be deployed. This ensures a) master is always ready to be deployed and b) merges go pretty smoothly. But really, do whatever feels most comfortable. -- Chris Wanstrath http://github.com/defunkt --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
