From: Fedor Sergeev <Fedor.Sergeev@Sun.COM>
To: Patrick.Higgins@cexp.com
Cc: git@vger.kernel.org
Subject: Re: git branch diagram
Date: Fri, 18 Apr 2008 12:39:52 +0400 (Russian Standard Time) [thread overview]
Message-ID: <alpine.WNT.1.10.0804181219420.1528@theodor> (raw)
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.
>
> 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.
next prev parent reply other threads:[~2008-04-18 9:08 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-17 17:00 git branch diagram Patrick.Higgins
2008-04-18 1:38 ` Sitaram Chamarty
2008-04-18 2:29 ` Roman V. Shaposhnik
2008-04-18 6:46 ` Karl Hasselström
2008-04-18 8:39 ` Fedor Sergeev [this message]
2008-04-18 13:07 ` Matt Graham
2008-04-21 0:30 ` Jakub Narebski
2008-04-21 12:48 ` Matt Graham
2008-04-21 13:06 ` Jakub Narebski
2008-04-21 13:07 ` Luciano Rocha
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.WNT.1.10.0804181219420.1528@theodor \
--to=fedor.sergeev@sun.com \
--cc=Patrick.Higgins@cexp.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).