Re: What's the best way to make my company migrate to Git?

From: Daniele Segato <daniele.bilug@gmail.com>
Date: May 24, 2010, 17:37 UTC
Message-ID: <AANLkTilhVbdaZgE4NINrl4RA6ArkeMstyFdnq9eD4o8B@mail.gmail.com>
In-Reply-To: <4BF94138.5000007@pileofstuff.org>

On Sun, May 23, 2010 at 4:52 PM, Andrew Sayers <andrew-git@pileofstuff.org> wrote:

> I agree that a lead developer moving a team from graphical SVN is a
> different problem.  I don't think git-gui does SVN, I couldn't work out
> how to make TortioseGit work with SVN, and I doubt EGit will like SVN
> very much.

EGit do not work with git-svn, it probably work just fine with "pure" git tough. I've seen TortoiseGit, it work very well but I found it somewhat more difficult then the command line: probably because I don't know where to find the command i daily use on git. I extensively use git grep and probably there isn't anything like it in TortoiseGit.

> You're also right that git-svn has limitations with merging and
> rebasing.  Specifically, don't use them unless you know what you're
> doing - see `man git-svn` for more.  Git-svn is also less
> newbie-friendly than either git or svn on its own.

Yes, that's why I'd like to skip git-svn and go directly with git, unless I know the people I'm teaching to can handle it.

Show 7 quoted lines

> Having said that, I'd still recommend you try moving a few developers to
> git during the lifetime of your current project.  In my experience,
> those developers most willing to try something new in the middle of a
> project are also the ones that want to get hacking right away on a new
> project.  Getting even one developer to start migrating now will be good
> practice for you, and will double the number of eyeballs looking at git
> issues later on.

Yeah, there is one developer tired of Subversion that asked me to teach him git(-svn). He's not in my team but I think it's a starting point :)

Show 11 quoted lines

> Slowing down for less than a week is a very ambitious target - I think
> we had about 2 weeks of noticeably reduced productivity, even when I'd
> done a lot of work to spread the pain over several months.  Starting git
> with a new project might reduce that time a bit - for example, there's
> no chance of uncommitted work in an SVN checkout failing to make the
> switch.  But it can be more expensive in the long-run, because you have
> to make all of your architectural decisions based on what you can
> explain to SVN users on day one - for example, my team took about 2-3
> weeks to understand how a commit is different from a push, and why they
> should care.  But because they understood before we made the big leap,
> we were able decentralise our workflow as much as we needed.

Probably it will be a svn-like architecture from the beginning, I'll not dare to move it any further until I know that developers are ready to handle it properly :) I'm not sure myself I can manage a workflow different from subversion (1 main server and N developers pushing to it) because I never did anything different.

> If you do go via git-svn, I'd recommend you read `man git-rerere` and
> set the config option "rerere.enabled" to "true" for all users.  I
> needed to blow away a few messy merges to fix rookie mistakes, and
> `git-rerere` would have made a painful experience much easier.

I did not know about this.. That's really interesting, I just enabled it in my local repo. Thanks for the hint!

Show 7 quoted lines

> Even if you go straight into git, you might think about finding/writing
> hooks to synchronise an SVN repository and a git repository.  There will
> probably be a few people you can't switch right away - e.g. a sysadmin
> that would need months to rewrite all his scripts, or a designer that
> doesn't want to learn a different tool just for your team.  Providing a
> semi-functional legacy interface for those people will let you raise the
> pressure on them more gradually.

Sysadmins shouldn't be a problem, we don't have sysadmins here and if the custumer require us to use his own versioning system we can't push them to git, so I think that wouldn't be a proble for us. But that's a good point.

Show 10 quoted lines

> I forgot to mention education in my previous post, which was actually
> one of the biggest problems during the move.  I was surprised how
> everyone had such different learning styles - some wanted to learn the
> theory then be left alone, some wanted to be told each solution at the
> moment they faced the problem, some wanted to learn by watching how I
> worked, etc.  The only real pattern seems to be that the busier people
> are, the more they like to feel they're pulling information out of you,
> and the less receptive they are when you push information at them.  I
> muddled through by trying to give everyone more of whatever they each
> reacted best to.

Thanks, I'll keep that in mind when I'll face the big switch.

Show 9 quoted lines

> Because my team needed time to unlearn a lot of these SVN issues, I
> didn't try to push much deep git tech at them early on.  A few months
> into the move though, it's starting to seem like a better idea.  One of
> my team-mates got me to start reading "Version Control with Git"
> (http://oreilly.com/catalog/9780596520137) - from what I've seen so far,
> I'd definitely recommend it to people that like book-learning and are
> ready to learn git without bringing their old SVN baggage.  On the other
> hand, you can cobble the same information together from various online
> sources if you prefer (http://book.git-scm.com/ is a personal favourite).

Thanks about the book suggestion, I'll give them both a try!

Regards, Daniele Segato