On Wed, Sep 17, 2014 at 02:06:52PM -0700, Tom Green wrote:
> I'm sure this is a dumb question from a beginner.... 

Pretty damn far from a dumb question!

> One product, one master (I guess). How is the best way to set up
> branches  I want to basically have 3 versions going concurrently:

Yes.  That would be the path of least surprises I'd say.  I've seen
some repos with several products on separate and completely unrelated
'histories'.  I would *not* recommend that!  Of course you might need
to think through what constitutes a "product" in your setting.  A
reasonable starting point is that anything that needs to be
independently releasable goes into its own repo.

>    1. STABLE version which our implementation team can safely
>       install on client machines
>    2. QA version for our QA team to work on
>    3. DEV version which will become the next QA
> 
> Here are some of the things I need to be able to do. 
> 
>    - When a QA version has gone thru testing and is deemed stable.
>      It needs to become the STABLE version. Similarly the DEV will
>      move to QA version.
>    - From time to time, I may want to take a feature (a few
>      programs) from DEV and move them to QA alone.
>    - From time to time we will find a bug in QA and (hopefully less
>      often) in STABLE. I need to be able to correct just that and
>      compile and test it.  I need to return to the QA
>      environment/version for that purpose. In other words, to
>      correct something in the QA (or even STABLE) branch, without
>      sucking my new development into the mix. And then to return
>      confidently to my DEV version.
>    - When I make a fix to the STABLE version, that correction needs
>      to be in the QA version and DEV versions as well. I don't know
>      if this is a manual or automated process, but I least I need to
>      be able to track it easily. Similarly QA fixes need to move
>      into DEV

It sounds like you'll need to play around with branches a little.
Just to get a feel for what they are and how they work.  You see, what
you point out above is *exactly* what a VCS will let you do (some more
easily than others, but still).

The commands to look at are

  git branch
  git merge
  git cherry-pick

> So what is the best way to set up and manage the branches? Is the a
> book or online article someone wants to recommend?

You got some good pointers in another answer.  Start there.

> Also, how do I take a program or two in one branch and move it to
> another?  TIA. --- Tom 

Again, it sounds like you need to read up just a little.  The bit
"take a program or two in one branch and move it to another" suggest
that you haven't worked much with VCS in the past.  So just read up a
little, and then return here with any questions that you have.

/M

-- 
Magnus Therning                      OpenPGP: 0xAB4DFBA4 
email: mag...@therning.org   jabber: mag...@therning.org
twitter: magthe               http://therning.org/magnus

The results point out the fragility of programmer expertise: advanced
programmers have strong expectations about what programs should look like,
and when those expectations are violated--in seemingly innocuous
ways--their performance drops drastically.
     -- Elliot Soloway and Kate Ehrlich

Attachment: pgpR3dp8Wlbrd.pgp
Description: PGP signature

Reply via email to