threads / discuss / 20962

git workflow for fully distributed mini-teams

Subject: git workflow for fully distributed mini-teams

## tl;dr

8 messages between Sep 16, 2009 and Sep 18, 2009.

replies: 7people: 3as markdown or json

Rustom Mody· Sep 16, 2009, 07:35 UTC · lore

I am trying to formulate (and understand) what it means to have a fully-distributed mini team workflow with git.

By fully distributed I mean theres no central repo -- not for pushing or even pulling; all communication is by email. By mini-team I mean: Not more than 5 programmers.

Heres a typical scenario.

There are 3 programmers A B and C who communicate by email who have started off from the same code base.

A's branches: dev, master, B, C B's branches: dev, master, A, C C's branches: dev, master, A, B

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 about checkpointing and restoring from botches?

Nicolas Sebrecht· Sep 16, 2009, 16:43 UTC · re: Rustom Mody · lore

Re: git workflow for fully distributed mini-teams

The 16/09/09, Rustom Mody wrote:

Show 16 quoted lines

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

Rustom Mody· Sep 17, 2009, 07:03 UTC · re: Nicolas Sebrecht · lore

Re: git workflow for fully distributed mini-teams

Rustom Mody wrote:

> By fully distributed I mean theres no central repo -- not for pushing
> or even pulling; all communication is by email.
> By mini-team I mean: Not more than 5 programmers.

On Wed, Sep 16, 2009 at 10:13 PM, Nicolas Sebrecht <nicolas.s.dev@gmx.fr> wrote:

Show 12 quoted lines

>
>
> 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).

Push? Fetch? How without a common repo?  [Sorry if this is totally noob!]

Show 13 quoted lines

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

I am really concerned about things like:

A commited something on the B branch, received a patch from B. That patch did not apply (or worse it applied -- on top of A's!) So ideally there should be an option that says (when A is on B branch and tries to commit) "Sorry buddy -- No commits here!"

Johannes Sixt· Sep 17, 2009, 07:28 UTC · re: Rustom Mody · lore

Re: git workflow for fully distributed mini-teams

Rustom Mody schrieb:

Show 6 quoted lines

> I am really concerned about things like:
> 
> A commited something on the B branch, received a patch from B. That
> patch did not apply (or worse it applied -- on top of A's!)
> So ideally there should be an option that says (when A is on B branch
> and tries to commit) "Sorry buddy -- No commits here!"

I think the most important thing would be that you send bundles around, not patches, so that you all can work with and talk about unique object names.

-- Hannes

Rustom Mody· Sep 17, 2009, 12:38 UTC · re: Johannes Sixt · lore

Re: git workflow for fully distributed mini-teams

On Thu, Sep 17, 2009 at 12:58 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:

> I think the most important thing would be that you send bundles around,
> not patches, so that you all can work with and talk about unique object names.
>
> -- Hannes

Thats what we need -- thanks a  'bundle'!

Rustom Mody· Sep 17, 2009, 13:52 UTC · re: Rustom Mody · lore

Re: git workflow for fully distributed mini-teams

On Thu, Sep 17, 2009 at 6:08 PM, Rustom Mody <rustompmody@gmail.com> wrote:

Show 5 quoted lines

> On Thu, Sep 17, 2009 at 12:58 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
>> I think the most important thing would be that you send bundles around,
>> not patches, so that you all can work with and talk about unique object names.
>>
>> -- Hannes

I started looking at git bundle and find things like master\~10. Whats the backslash doing?

Tried running git bundle create with and without the backslash -- it produced the same bundle.

Looked up tilde-expansion in bash and I gather bash does things to the ~ only on beginning of words whereas as far as I can see git uses ~ only at the end of words like master.

What am I missing?

Johannes Sixt· Sep 17, 2009, 14:47 UTC · re: Rustom Mody · lore

Re: git workflow for fully distributed mini-teams

[On this list, we reply to all, so that the Cc list remains]

Rustom Mody schrieb:

> I started looking at git bundle and find things like master\~10.
> Whats the backslash doing?

It's intended as markup for the pipeline that generates the documentation from git-bundle.txt. Either the markup is incorrect, or there is a bug in the pipeline, because I only see it in the generated HTML. Ignore it.

-- Hannes

Rustom Mody· Sep 18, 2009, 07:01 UTC · re: Johannes Sixt · lore

Re: git workflow for fully distributed mini-teams

On Thu, Sep 17, 2009 at 8:17 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:

Show 9 quoted lines

> [On this list, we reply to all, so that the Cc list remains]
>
> Rustom Mody schrieb:
>> I started looking at git bundle and find things like master\~10.
>> Whats the backslash doing?
>
> It's intended as markup for the pipeline that generates the documentation
> from git-bundle.txt. Either the markup is incorrect, or there is a bug in
> the pipeline, because I only see it in the generated HTML. Ignore it.

Seems to be there in my git-bundle.txt as well as git-bundle.html. So its probably the markup not the pipeline.