Re: GIT - releases workflow

From: Shawn Pearce <spearce@spearce.org>
Date: Dec 13, 2006, 11:14 UTC
Message-ID: <20061213111450.GB31177@spearce.org>
In-Reply-To: <20061213105614.GB9484@spearce.org>

Shawn Pearce <spearce@spearce.org> wrote:

Show 13 quoted lines

> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > > On Tue, 12 Dec 2006, Sean Kelley wrote:
> > > > 
> > > > > I was wondering if anyone could share ideas on how best to use GIT to 
> > > > > handle releases for those working with a remote GIT repository?  Do you 
> > > > > create a branch and push it to the remote?  Thus you have a new branch 
> > > > > referencing the particular release?
> > 
> > BTW, if the maintenance releases are sparse and long between, you can 
> > actually create the branch from the tag, fix, and tag with the new version 
> > number. No need to start the branches early.
> 
> Indeed.

[snip]

Show 9 quoted lines

> The script is really meant for QA people to take in topic branches
> from developers and apply them to a specific version, test that new
> version, then ship that new version.  Some of the QA people I work
> with aren't developers and have a somewhat difficult time making
> a build from source; this script makes it a pretty simple process.
> 
> The version number incrementor is smart; its based off commit
> lineage.  It can automatically create a "2.0.1" tag when "2.1"
> has already been made but "2.0.1" is a bugfix of "2" or "2.0".

What I really should have said was the general idea here is that we never even have a trunk.

Developers work on topic branches and share/merge those individual branches as necessary to evolve a topic. When its suitably cooked in developer land it gets sent off to testing by being pushed into a someewhat descriptive ref under refs/heads/ready.

Testing can then accept topics by merging them together and creating tags via the described script.

Developers update their still cooking topic branches when necessary by pulling in the tags. git merge is smart enough to dereference the tag and generate the merge. Normally this is held off to the latest possible moment, and only to make sure there aren't any unexpected surprises from the merge waiting for the unsuspecting QA person.

Developers start new topic branches off the relevent tag they need to work on. New features are often made off the latest tag from QA; bug fixes are often off the tag currently in production.

So like I said, we're basically trunkless and happy. Tag happy. Thank you Linus, et.al. for packed refs!