OK, I see what you're saying Tekkub. Thank you for all of the help and advice.
Ken On Jul 22, 2:46 pm, Tekkub <[email protected]> wrote: > Peter, In that workflow, you have one person performing the merging, > staging, and testing. You can stage multiple times if you like, and "save" > those staged points in temporary branches. If you've got multiple repos > that need to be tested together, again, you have one person that's > coordinating all of that. Essentially, developers are assigned tasks by > this person, fix them in topic branches, push them, and pass things on to > the coordinator. The developers test locally during dev of course, but > never worry about the process of getting things tested for QA and deployed > to production. They simply branch off master because that's what is live, > and what needs fixed. So there effectively isn't a "freeze", the > coordinator just might not assign out or merge in feature branches. > Ken... > 1) Well, first off, the person doing all the merging should never have a > dirty working copy to begin with, merge won't work if he does. The hard > resets aren't really destructive here because you're resetting to other > branches. Yes, you may lose the last staged point, but staging is a > fleeting thing anyway and you rarely don't care about that last point. If > you did, you would have a normal branch there, or tag if you want a > permanent reference. Remember that branches are just pointers, and in this > workflow you're just moving the staging branch around while you prep things > for production. Everything you want to keep will end up in master when you > deploy to production, after which you'll delete the topic branches that have > been merged. > > 2) git does not push tags unless you tell it to. By default it only pushes > the reference you tell it to push, which is usually a branch. You can push > individual tags by name, or add "--tags" or "--all" into the push command to > get tags or tags and all branches. > > Tekkub > Github Tech Support > http://support.github.com/ > Join us on IRC: #github on freenode.net > Discussion group: [email protected] > > On Wed, Jul 22, 2009 at 10:30 AM, Ken <[email protected]> wrote: > > > 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 -~----------~----~----~----~------~----~------~--~---
