Tekkub, Thank you for putting together your description of a typical workflow. I have a couple questions/concerns:
1. I'm a little nervous about the hard reset in step 3. The hard reset is going to effect the HEAD, the Index and the Working Directory (including removing new files and losing modifications to existing files) for the whole repository. The destructive nature of that action worries me. Couldn't you just do step 1 and then create a new staging branch each time in step 2 and skip step 3, then do steps 4 - 12 followed by deleting the staging branch at the end? It just seems safer to me but maybe I'm missing something here. 2. In step 11 you say to "push master and tag". Is that because the git push command doesn't automatically push tags to remote servers? Thanks, Ken On Jul 22, 2:06 am, Tekkub <[email protected]> wrote: > Peter, > 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. > > A typical workflow would be like this: > * branch off master (the code you know is on production), make new features > or bugfixes, repeat many times with many branches > * checkout staging > * hard-reset to the first branch you want to stage > * merge all other branches to stage > * push, may require a --force, but probably won't > * deploy to staging server from staging branch > * test on staging... everything is good to deploy to production > * checkout master > * merge staging, this should always do a fast-forward merge unless you've > been working in master... which would be bad because those changes were not > deployed to staging to test. > * create a tag! > * push master and tag > * deploy to production from master > * GOTO 10 > > The reason I like this method is that it helps other developers know what's > on the servers. There's no need to ask what was last deployed, you know > that staging is on the staging server and master is on the production > server. Tags help you find previous production deploys. Staging deploy > history doesn't really matter, only the current deploy, so you only need the > branch for that. Also, by never working directly in master, you avoid > issues of people "stepping on each other's toes". Everyone-in-trunk is best > left for svn, where it's anywhere from a minor pain to a huge headache to > branch. > > If a staged deploy is bad, you can reset back, re-merge, and re-deploy until > you're happy. after it's deployed to production, you see at a glance what > branches aren't merged into master, and fix them up. > > 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. > > 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 11:45 PM, Icebreaker > <[email protected]>wrote: > > > 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 -~----------~----~----~----~------~----~------~--~---
