As long as your colleagues are only interested in using the same features
as are available with SVN, the only advantage to using Git is performance
IMHO. And this you only really start noticing with either large code-bases,
or very old ones (lots of commits).
If SVN performance is not annoying, and your team has no problems merging
branches and stuff like that, by all means let them stick to using SVN (and
use git-svn for yourself).
In the first company I tried to introduce
I failed at first, even though lousy SVN performance was perhaps the
biggest technical annoyance people had in their daily work. I couldn't
convince the team to switch all in one go, so I set up a git-svn
to allow people to try out git on the code base, while still being
backwards-compatible with SVN. This allowed people to try out git on the
real code base while still using SVN, thereby avoiding the dangerous "cold
I started with the colleague I shared office with, as I could show him
little git tips every few hours, and help him out when he got into trouble.
Together we then managed to convert a couple of the early adapters (the
team members who are always interested in fancy new stuff). The plan was to
gradually win the whole team over, and then make a complete switch when
everyone (or most) felt ready for it, but around then I switched jobs.
I reckon I spent about 6-8 months converting just a small handful of
colleagues, so I appreciate this being hard work!
In my next job I spent just a few months getting the whole team over on
git. Much smaller team, and much more segmented code-base (easier to
convert bit-by-bit to git repositories), were some of the reasons it was so
much easier this time around.
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To view this discussion on the web visit
To post to this group, send email to email@example.com.
To unsubscribe from this group, send email to
For more options, visit this group at