Re: git branch diagram

["Roman V. Shaposhnik" <rvs@sun.com>]

On Thu, 2008-04-17 at 11:00 -0600, Patrick.Higgins@cexp.com wrote:
> 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. I put together the attached 
> diagram (done with graphviz so some things are not in the most logical place)

Just as a usability comment: I believe that you should color-code or 
enumerate your arrows based on what part of the workflow they belong to.

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

Speaking of diagram: when you say that inter-repo arrows are pulls, 
does it mean that you are not allowing developers to push their changes
back to the origin? If you're really trying to build your workflow  
around the pull-only, who does the pulling? IOW, who controls the
"Project Repo" (the big box in the middle)?

> Does my diagram make sense? Are there any suggestions or corrections?

Here are my comments (beware: they do not come from a Git guru, although
I'm trying to make my employer take Git seriously as well):
   * It looks like "Integration Repo" is really a Superproject that
     consists of submodules. Was that the intention?
   * do you really need dev[123]/master branches in the "Project Repo"?
   * I don't really understand what the smaller boxes labels "Local
     branches" are supposed to represent.

Thanks,
Roman.