You may also take a look at Limerick Rake: http://github.com/thoughtbot/limerick_rake/tree/master
Which adds helpful rake tasks for managing a git staging and production branch which is forked off of master (as well as other helpful things). I became aware of this from the Thoughtbot Suspenders rails standard app. Suspenders also has the deploy configured so that capistrano uses these staging and production branches as its source. e.g. "set :branch, "staging"" http://github.com/thoughtbot/suspenders/blob/cbad9a9a27b1d1b8dd2dc23850b87cebf71fa958/config/deploy/staging.rb Once this is setup you simply do 'rake git:push:staging' and 'cap deploy' which merges your master onto the staging branch, and pushes it to staging server. When you're happy with that a 'rake git:push:staging' and 'cap production deploy' handles the last mile. Its worked well for me. To each their own. Cheers. On Jul 21, 3:31 pm, Tekkub <[email protected]> wrote: > Ken, re: production/staging... I've not had to deal with this one directly > myself, but the approach I've seen (and liked) is to work in topic branches > (as above), deploy to staging from a "staging" branch, and to production > from master. This way other developers know what is on the servers by the > staging and master branches. When a staging deploy is to be made, the > staging branch is reset to the first branch, then any others merged in. > This is pushed (may be a force-push, history doesn't matter much for this > branch), and the deploy ran from that branch. When everything tests out, > master is fast-forwarded to staging (this should always be a fast-forward > merge), tagged, pushed, and deployed. All new topic branches (unless > they're a bugfix for an old tag) are created at master, unless they depend > on another branch that has not yet been deployed, in which case they branch > off the other branch. > Tekkub > Github Tech Support > http://support.github.com/ > Join us on IRC: #github on freenode.net > Discussion group: [email protected] > > > > On Tue, Jul 21, 2009 at 4:07 PM, Ken <[email protected]> wrote: > > > Wow - there sure are a lot of ways to approach git workflow > > management! I guess that's a good thing - lots of choices. Chris, it > > seems to me your approach is pretty simple and straightforward. > > That's what I'm looking for. I figure the more simple it is the less > > chance I have of screwing it up. :-) > > > Tekkub and Peter - I appreciate your assistance, as well. Tekkub I > > think I will supplement my plan with tags to mark version releases > > (bug fixes and new features) to provide some flexibility down the road > > in case my basic approach has flaws or in case I just need a little > > more flexibility. Peter, I read with interest your approach using > > rebasing and cherry-picking. I'm going to take those ideas and see if > > I can improve my plan. > > > One area that hasn't really been addressed here is which branches to > > use for deploying to staging and which to use for production and how > > to handle situations where errors are found during testing with > > staging. Also, while I am a single developer, I do have two machines > > (just in case one breaks) and I need to figure out exactly where and > > when to do pulls from github down to the other machine... > > > Thanks! Ken > > > On Jul 21, 11:18 am, Chris Wanstrath <[email protected]> wrote: > > > On Tue, Jul 21, 2009 at 10:12 AM, Ken<[email protected]> wrote: > > > > How do you handle bug fixes? Do you make your changes in the master > > > > branch and then merge them into all of the "new feature" branches? > > > > Or, do you make a new branch for each bug fix and then merge those > > > > changes into the master branch and into each of the new feature > > > > branches? I guess I'm confused on how you keep the new feature > > > > branches up-to-date with bug fixes... > > > > For bug fixes we just create a branch and fix the bug, then merge it > > > into master. > > > > To ensure the feature branches get the fix, we just occasionally merge > > > master into them. For instance: when I'm ready to merge a feature into > > > master, I make a third branch (feature_merge) and merge in master then > > > fix any conflicts. If that went smoothly I either replace master or > > > merge the feature_merge branch into master then clean up by deleting > > > the feature branches I created. > > > > So really: merge bugs into master then frequently merge master into > > > feature branches. > > > > -- > > > Chris Wanstrathhttp://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 -~----------~----~----~----~------~----~------~--~---
