I think that some of the workflow from the git git repository is a great model. The relevant bit for you is that there are four primary branches - master, maint, next, and pu - and that releases are tags, not branches. * master is totally stable, working toward the next release, which will be a tag along this branch. * maint is maintenance, and is regularly merged into the other branches. Maintenance releases will be tagged along this branch. * next contains stable but not totally proven changes which should eventually be merged to master. * pu contains unproven proposed changes, which will hopefully be merged to next at some point.
Using tags instead of branches avoids changing branch names every time you have a release, and the branch names will help you keep your development in good order. Something you might modify here is to have a maintenance branch for each past release (like v1.x) and keep that branch around as long as that version is being maintained. You just have to be careful to merge all of them upward - v1.x into v2.x and v2.x into master, for example. You can also mess around with the number of classes of stability/tested-ness. The important bits are using tags, and using constant names like master and maint. This won't modify the commands you mentioned using. I don't know anything about Capistrano, but long as it's just grabbing from the master branch, it won't change. It will require pushing more branches to github, but that's just extension of what you're already doing. If you're curious about the git git workflow, there's a description of it within the repo, accessible from gitweb. It's obviously a way larger scale than what you're doing (or what I do), but it's well- written and got me to make sure I was thinking about things. http://repo.or.cz/w/git.git?a=blob_plain;f=Documentation/howto/maintain-git.txt;hb=HEAD Jeffrey On Jul 20, 5:37 pm, Ken <kohud...@gmail.com> wrote: > Hi All, > > I am close to deploying version 1.0 of a new Ruby on Rails > application. I am a single developer (no team complications) and I > have been using Git and Github as follows: > > a. Make changes to source code and commit to 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 staging server using > github as the repository. > d. Repeat the above steps for each change. > > 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. > > Thank you and best regards, Ken --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Git for human beings" group. To post to this group, send email to git-users@googlegroups.com To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/git-users?hl=en -~----------~----~----~----~------~----~------~--~---
