On Thu, 17 Apr 2008, Patrick.Higgins@xxxxxxxx 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.
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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
