Re: git workflow for fully distributed mini-teams

[Nicolas Sebrecht <nicolas.s.dev@gmx.fr>]

The 16/09/09, Rustom Mody wrote:
> 
> A's best practices (and invariants) are:
> I (ie A) develop on dev (or other topic branches).
> I only merge onto master; never commit.
> I never work on nor merge onto B and C.
> When B sends me patches I apply them to the B branch likewise for C.
> Thereafter I merge that branch onto dev or master.
> There are no tracking branches because there are no remotes -- no
> central repo. [not clear about this]
> 
> B and C have corresponding practices/behavior.
> 
> So the questions...
> 
> Is there a better way of doing things?
> Can some of these practices/invariants be enforced by scripts/options etc?

What's may be hard here is about "releasing topic". With a "maintainer
oriented workflow", the status of each topic is clear (either "won't
merge as is, needs more work" or "should be good enough, is merged and
aims to be in the next release").

In the fully-distributed workflow you describe, the state of the topics
looks hard to know. Who releases what is not clear.

Also, I see a duplication of the same work for all the developers in a
team: "merge my topics with topics from others". This could be solved
with one more common repository wich could stand as a "virtual
maintainer repository" where each developer could release any topic.
Topics that don't need any more work would have to be merged in a
dedicated public branch ("next"?) for testing, and topics that aren't
good enough into another dedicated branch ("pu"?). So, each developer
would have to push publishable merges into this repository. This way,
everyone could use the merges done by another developer (by doing a
fetch and rebasing of his current work on top of it).

Notice that this is all about "everybody uses the same base for his
current work" (to avoid per-developer scratch on merges) and "don't let
everyone do the same work on his own" (to avoid duplicate work).

> What about checkpointing and restoring from botches?

I think this is be easily doable (against your described workflow) with
good conventions in branch names. Topics like "pending-topicA",
"pending-topicB", etc that would have to be merged (using a script) into
a "all pending topics" branch should do what you want, no?  Restoring
from botches would mean removing the crappy branch and re-execute the
script.

Hope this helps.

-- 
Nicolas Sebrecht