Teaching people the basic mechanics of git is easy. Convincing them that it’s worth the effort is hard.
My current workplace uses CVS (still!) and there’s an initiative by a couple of developers to migrate people from CVS to Mercurial. It’s not git, but the fact that it’s a DVCS is still a pretty good advance. We’re currently going through a setup phase where people are testing the waters on a sandbox server with hg installed and it seems like the full jump may actually happen before I leave for school.
And as nicely as this story is going, it was rather difficult to get to this point: the meeting leading up to the decision for a sandbox trial took hours.
That was a real eye-opener; I swallowed git down for a college course and took a lot of its features for granted. It’s much different watching people trying to shake off a CVS mentality and cope with a new version control paradigm. I had it much easier.
Looking back, I think it’s a lot easier to work from a clean slate. Someone without the preconceptions of a commit or a checkout isn’t going to experience the frustration of adjusting to the same terminology, but different definitions. However, developers who’ve learned a different kind of version control are far from damaged goods; some friendly re-education will do the trick.
And re-education is a very relevant term. Because the argument to shift people from one version control paradigm to another requires that people understand two things:
- Workflow
- Problems solved
Workflow
The tricky part to this is that you’re not only explaining the workflow in DVCS, you’re also clarifying the workflow of CVS to the few that never needed to fully comprehend CVS’ workflow.
How naughty, people using technology that they don’t fully understand!
It’s bound to happen. I don’t even know what all of the buttons in my car do–only the important ones matter to me.
That being said, I don’t agree with letting people go wild after teaching them a couple of magic words. At least not with DVCS. If you’re going to restrict yourself to teaching the high frequency commands, then you had no business endorsing git or hg. You’d only be using the tool through familiar methods, and the whole point of teaching a new version control paradigm is that the familiar is flawed.
Diagrams are king. People are going to need an anchor for their mental models; save them the trouble and make the damn diagrams.
Get diagrams of the current version control workflow and contrast it with the new one. Commands are just actions: all they do is get you to another state. It’s the states of the code that matter; the fact that states exist and how they differ is what people need to leverage.
Problems solved
Looking back on that meeting, a good amount of people needed legitimate reasons for why hg was worth the pain and those reasons had better not boil down to “because it’s awesome.” Because to those same people, “CVS is awesome.”
Expecting resistance, taking it in stride, and being understanding is probably the best way to go about it. But in the end, you’re forcing an idea that fixes a technology that wasn’t necessarily broken. At least not at the time of its conception. And that’s why it’s re-education (did you forget already?). You’re dethroning a god CVS to these folks.
Go about this delicately. When people can understand the difference in workflow between different paradigms (those diagrams are a godsend if you prepared them in advance), show first that the new paradigm can do everything that the former paradigm can do.
DVCS has a couple of downfalls; feature lacking is not one of those downfalls.
Show the commands that need to be run to accomplish what the audience wants. A live demo is best–it’s something that needs to work in theory and in practice. It might be a good idea to try things out beforehand on whatever you’d got set up before you perform the demo. And once everyone is happy and wondering why we’re switching over to DVCS again, that’s when you bring out the big guns: use cases
Show common use cases with issues that were accepted as facts of life when dealing with CVS. Now show them that life doesn’t have to be so hard with DVCS. The 21st century is pretty awesome.
Merging and branching are where it’s at; I really hope you leverage it in your use cases because this is where all other version control paradigms fail. One does not branch in CVS with a realistic expectation of merging at some point in the future. You’d just be asking for punishment.
Closing note
Let’s not pull any punches here, DVCS is very complex. More so than any other version control paradigm out there.
Too many people glaze over this complexity detail when going over the cons of switching to a DVCS. If you’re a solo developer who likes to develop using GitHub, then it’s not a big deal; you’re having fun and killing time. Now if you’re on a team that has a coding velocity to maintain, then stumbling to a halt on all of your features and bug fixes to learn a new version control paradigm becomes very expensive.
But in return for this complexity, you get power.
After the meeting was over, people asked for online tutorials to use hg. Hindsight is 20/20, but Joel Spolsky got this ‘how people should learn DVCS’ thing right the first time.