Re: git branch diagram

[Jakub Narebski <jnareb@gmail.com>]

<Patrick.Higgins@cexp.com> writes:

> I am trying to get my employer to start using git and have found the
> distributed model and git's branching to be one of the hardest parts
> to explain and understand. 

Take a look at description of version control and distributed version
control at BetterExplained, and slides from presentations / seminars
which you can find in GitLinks page at git wiki.

> I put together the attached diagram (done with graphviz so some
> things are not in the most logical place) to help explain things to
> my coworkers.
> 
> Unfortunately, I don't understand things well enough myself to know
> if the diagram is correct or not. I read in the stgit docs that
> developing directly in the master branch is discouraged by
> convention, but I don't really understand why. The git tutorial
> shows work happening directly in master, so I wasn't sure if that's
> a convention that only makes sense for stgit or for plain git, too.
> 
> Does my diagram make sense? Are there any suggestions or corrections?

It is much too complicated. IMHO it would be better to explain the
idea of remote branches first (separate diagram), then simplify
diagram by showing only relationships between repositories:
relationship between branches is impled.

Perhaps adding what branches are supposed to be found at given
repository...

BTW. do all transfer is pull (or fetch) only, or are there pushes and
exchanging patches via email?

> In my diagram, I am assuming that most developers work in master,
> and make branches for their own long-lived projects and experimental
> things.

For example git itself, as a project, uses three long-lived branches:
'maint', 'master' and 'next', uses 'pu' (proposed updates) branch as
propagation / review mechanism for short-lived tipic branches.

-- 
Jakub Narebski
Poland
ShadeHawk on #git