Workflow question

[Russ Brown <pickscrape@gmail.com>]

Hi,

I've been trying to think of a git workflow that we could use to replace
our current svn/svk setup without simply using git in exactly the same
way that we use svn/svk.

Basically, we develop, maintain and enhance a website. On the central
repo is trunk which represents live, and any number of project branches.
Developers don't use local branches: they check out the project branches
they're working on and commit to those. Developers merge from trunk to
project branch from time to time to keep them current, and when a
project rolls out the branch is merged to trunk.

In addition to the obvious advantages that git would give us (such as
properly tracking that code author as opposed to the person who did the
merge), I'm wanting to gain the following benefits:

 * The repository is very large (multiple gigabytes) and mirroring using
svk obviously takes a lot of time and space, so I'm keen to bring that
down, most likely by the developer not needing to mirror branches he
doesn't care about, or by being able to throw away branches he's done with.
 * The repository is full of revisions that fail review (or break
things) and are fixed by subsequent revisions. We'd much rather be able
to have the developer fix his revisions before they get committed
'upstream' (whatever that ends up meaning).

I asked earlier about the email-based model that git itself uses, and
while it appears to work very well for a widely-dispersed open-source
project, I think it will be too cumbersome and slow for a fast-paced
internal development team who make a number of live releases every day.

So, I've been thinking and have come up with this, which I'd appreciate
comments about:

 1. On a server we stick a git repository which contains the master
branch, which represents what trunk did (i.e. the live platform). This
branch contains the full history for the live platform.
 2. On the same server we clone that repo to create a second repository
which is the developer area. In this we track master from the live repo,
and also create project branches.
 3. Developers clone this developer repo, but I'd like them to be able
to decide which branches they actually want to clone from that
repository rather than simply cloning them all. Is this possible?
 4. Developers create a local branch of the project they
are working on and commit to that.
 5. Once they think they're done, they publish their branch to the
development repo and request for comments.
 6. If all is not well, the developer creates a new local branch and
moves good revisions from his previous one to the new one, modifying
things as he goes, and republishes his new branch.
 7. If all is well, their works gets merged or rebased onto the main
project branch, and once that's ready it gets pushed to the master and
rolled to live. The developer's individual branches get deleted from the
dev repo since they're no longer required.
 8. From time to time the master branch gets merged to the project
branches. Developer's local branches can be rebased against the project
branch as they please.

Firstly, is all of this possible, and if so would it be considered a
good way of going about it?

Any comments appreciated.

-- 

Russ