Re: git branch diagram

From: Fedor Sergeev <fedor.sergeev@sun.com>
Date: Apr 18, 2008, 08:39 UTC
Message-ID: <alpine.WNT.1.10.0804181219420.1528@theodor>
In-Reply-To: <911589C97062424796D53B625CEC0025E460C3@USCOBRMFA-SE-70.northamerica.cexp.com>

On Thu, 17 Apr 2008, 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) to help explain things to my coworkers.

One bit of advice - make at least two or three versions of this diagram, with varying levels of complexity (say, complex one for integrators and simple one for developers). Full diagram might appear to be very intimidating to newcomers :)

Depending on their background your coworkers might not like the whole idea of branching (because of prior bad experience with branches and merges). In my case the very word "branch" was not always accepted nicely.

My own experience in a similar situation (which has not yet been fully resolved, so take my words with a grain of salt) shows that for the initial acceptance it is better to devise a scheme that does not involve branching.

People will learn branching and will appreciate git's flexible branching in future, but for starters it might appear to be better to restrict amount of branches to master + origin/master.

Show 6 quoted lines

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

That is really up to your policies and your trust to the developers. It is harder to screw up a master in Git than it is, say, in TeamWare.

But I would not let everybody in my project to freely go and do stuff in master. And I definitely would not make it a development requirement, as TeamWare background makes my coworkers shudder and sweat of a very thought of touching master.

Your milage might definitely vary.

regards,
   Fedor.