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
-~----------~----~----~----~------~----~------~--~---
