# Why don't more universities teach revision control?

In the answers to this question, it's suggested that one of the most common things that CS graduates still need to learn to be employable developers is revision control, and by inference that many CS graduates don't learn how to use it while at university.

This surprised me, because on my CS* course we started using revision control (git) on literally the first day of the course, and a lot of the work we did during our degrees would have been much more difficult without it.

Taking this claim at face value, if knowledge of revision control is both a) useful during the degree and b) desirable afterwards, why don't more universities teach students to use it?

I understand that this could be seen as primarily opinion based so, if possible, I'd be particularly interested to see actual reasons given by the institutions themselves or people who teach CS (particularly software engineering) courses.

*I should clarify that my course was in actuality a Computing degree (BEng) and so contained more practical components than others may do.

• Do you mean version control? – ErikE Sep 13 '17 at 23:56
• @ErikE: One of those terms not worth being nitpicky about ;) stackoverflow.com/questions/1056912/… – Sebastian Mach Sep 14 '17 at 8:53
• For the same reason that mechanical engineers never have to pick up a screwdriver. – J... Sep 14 '17 at 10:13
• Why Excel isn't thought in CS? – Calculator Science Sep 14 '17 at 11:46
• Extreme example: using a computer and/or typing with more than two fingers is also desirable for employment and useful during the degree. Why is it not taught in a CS curriculum (or a Philosophy curriculum, as I expect philosophy students to type long essays as well)? – Tobia Tesan Sep 14 '17 at 12:19

I suspect it's a combination of several factors:

1. Version control isn't that challenging to learn (assuming you know how to use the command line). It's something you can trivially understand by following a few tutorials online -- I'd argue the hardest part is actually finding the right tutorial (there are tons of garbage "how to use Git" tutorials out there, and surprisingly few good ones, for example).
2. Despite that, it can be hard to find time to fit in the command line and git. You'll probably need to spend at least 30 minutes talking about both things, and if you have a lot of material you need to cover, it can be hard to squeeze that in without compromising on something else.

In particular, it's worth noting that you can't necessarily just add in new material somewhere and shift everything over. You need to make sure your change maintains the overall tempo of the course, make sure no topic "overlaps" oddly over a weekend or a holiday, need to make sure students are still being taught the material they need a sufficient amount of time before you make related HW due... If the original course was competently designed, it's probably a well-tuned engine where every minute matters, so adjusting it will require some degree of effort.

3. If your university didn't find time to squeeze in version control, you'll be told to learn it on at least day 1 of your first internship or job.

(And they'll probably do a better job of teaching it! It's hard to teach the value of things/give students the opportunity to practice things like branching, rebasing (if you're using git), using specific workflows, etc. in a university setting -- those sorts of more advanced operations are really only useful in larger teams working on a long-term project.)

4. You mentioned that your intro course covered git on day 1. I can see an instructor considering against that approach if they want to prioritize moving to programming as soon as possible to try and "hook" the students in with instant gratification. (If you're completing new to programming, I can imagine learning to use tools like version control would be relatively dull and sort of a bother -- you don't really get to see the payoff until you start tackling more complex projects later on.)

So basically, it's material that's difficult to fully cover (where the subset you can cover is easy to learn yet still takes up an awkward amount of time), and that the student is going inevitably run into and learn without any real difficulty anyways.

None of the issues I pointed out are insurmountable, of course, but if you toss in inertia into the mix, you can see why some schools would never get around to rejiggering their curriculum to fit version control in.

I personally think it's worth teaching version control anyways (I'll go even further, actually -- I think schools that don't teach version control in some capacity are doing their students a major disservice), but can't deny that it can sometimes be logistically challenging to work that material in.

• Also, it's worth noting that the university and the instructors themselves don't necessarily get any huge benefit out of using version control (it's sometimes the opposite, in fact: somebody needs to set up and maintain all the infrastructure and tooling). Rather, it's mainly the students who get the benefit. – Michael0x2a Sep 11 '17 at 18:02
• @walrus -- oh, don't get me wrong. I think adding an extra, lightweight course containing all of these additional "things you should probably know" is a pretty decent way of solving this particular problem -- that's exactly what my university does, in fact. But the path of least resistance for a typical instructor is to modify their (existing) course, and my point is that can sometimes be a bit challenging. – Michael0x2a Sep 11 '17 at 22:09
• "Version control isn't that challenging to learn." I disagree with this. When I finally did need to learn version control, it took me several weeks to really get the hang of it, and I continued to learn more about it for years. And there are many, many wrong ways of using VCS that are easy to fall into if you aren't taught well or don't have a deep enough understanding of what you're doing. Proper VCS usage could easily cover multiple lectures, if not an entire unit in a class. – Kevin Sep 12 '17 at 0:16
• I second @Kevin's comment. See e.g. this or this question. At the very least, I certainly think it's wrong to say that you could learn Git trivially easily. This is supported by the fact that Git's primary documentation includes a 574 page book, and that book doesn't even explain how Git works, a topic which the same author wrote a separate 120 page book on. – JBentley Sep 12 '17 at 14:06
• @Michael0x2a I've had to teach Git in a commercial setting a few times. What I have found is that if you can start from "learn the correct model of how git models everything under the hood," and then learn how to use it, Git is easy. However, if you cannot justify learning the entire model before doing anything, it's very easy to develop wrong models in one's head. I still grapple with issues regarding the index because I learned it wrong the first time. Honestly, I find most people want to being seeing productivity as they learn, not after they learned it. – Cort Ammon Sep 12 '17 at 19:17

# Teaching revision control as part of CS course.

## Against

Revision control is not a computer science thing, it has nothing to do with computer science. Though it is a software engineering tool.

## For

Everybody should learn revision control, if they use a computer. Even from non-technical subjects. Even though it is a software engineering tool, it can, and should, be used by everyone, in every subject.

When dealing with MS-Word documents and other non-diffable objects, a revision control system that uses / or allows locking should be used. This precludes distributed revision control. For this use case Subversion (svn), is preferable to git or mercurial (hg).

• True story: I did quite a lot of theatre at uni and did an entire play script in LaTeX, which I of course version controlled using git & github. The director (not at all technically minded) was confused, to say the least. – walrus Sep 11 '17 at 22:07
• There are tools that can diff MS-Word files, which can be plugged into your version control system – JoelFan Sep 12 '17 at 19:51
• @ctrl-alt-delor, blog.martinfenner.org/2014/08/25/using-microsoft-word-with-git – JoelFan Sep 12 '17 at 20:03
• @JoelFan that pandoc tool looks awesome. I have many uses for it. Looks better than what I was using for a few task, plus I have other jobs for it. Turns out that I already had it, so I just installed it. – ctrl-alt-delor Sep 12 '17 at 20:21
• As such, in a modern academic environment where most work is prepared to hand in digitally, revision control software of some sort should be the first thing you're taught when you go to college, or even in high school, not just for CS students but for everyone. – R.. GitHub STOP HELPING ICE Sep 12 '17 at 21:16

I'll stick my head above the parapet, and offer that the people teaching these courses won't have been taught about version control as part of their degree courses. I certainly remember that the hassle of learning about how it worked (and some doubt/uncertainty) meant it wasn't something I adopted until I was forced to by work requirements. At the time it felt hard. Now, if I want someone to see some code, I give them a 'git clone' command line...

There seems no real justification to avoid introducing version control in its simples form fairly early on. You can argue that it isn't needed, which may be true, so there is no need to go overboard on the detail. What is most important is to instill the understanding that version control makes life easier.

It feels that GIT works more easily than RCS, although that might just be an effect of the concepts being more familiar to me now.

• Are people still using rcs? – ctrl-alt-delor Sep 11 '17 at 18:26
• No, don't think so - but good version control feels like a fairly new thing, and there is a great temptation to teach things as you learnt them, as your tutor learn them - etc. – Sean Houlihane Sep 11 '17 at 18:36
• I think this is probably the main factor. The lifecycle (and inertia) for intro CS courses is quite a bit longer than the cycle for programming developments. Having a robust, readily available version control system which can be instituted on a personal level and doesn't require major support infrastructure (e.g. a server) is relatively recent, especially when measured against how frequently departments revamp their CS courses. As more people get familiar with Git and the like, I imagine it will be incorporated more widely in the "best practices" suggestions/requirements given to students. – R.M. Sep 11 '17 at 18:38
• @ctrl-alt-delor Yes, with a modern wrapper. – CL. Sep 12 '17 at 17:18

The main thing you need version control for is for group coding projects.

When I was taking CS back in the misty past (mid 80's), the only class that had a group coding project was my Software Engineering course. I remember complaining to a TA about updates from teammates wiping out my changes, and him mentioning to me off-handedly that our OS (VMS) actually had a program to help deal with that.

Perhaps these days that info would be given up-front (I sure hope), but I think they can be forgiven for not teaching me about it before then, simply because without having the experience of working in a team, there'd be no need for it.

Typical practice back then, and I gather today as well, was to train CS students to work alone. Students coding all by themselves and not going to peers for help is treated as virtuous behavior, while actually coding in concert with another human being is treated as cheating so vile, it merits expulsion. So I think its somewhat understandable that they wouldn't train students to use tools that encourage that evil behavior.

Ironically, when I did job interviews my Senior year, I had a least two interviewers who were only interested in my grades in the Software Engineering course, and only interested in talking about how that one course went for me. Seems like a bit of a disconnect there...

• The main thing you need version control for is for group coding projects. citation needed? I've seen many instances where people do all sorts of things where VCS would be beneficial. Not the least of which is the CS rite of passage, doing an accidental rm -rf on something important. – enderland Sep 11 '17 at 16:22
• Interesting; in my course (graduated this year) we did five big, term-long group projects and probably a couple of dozen smaller group coursework pieces, plus more pieces of coursework that could be done individually or in small groups. About the only work that was strictly individual was the exams. – walrus Sep 11 '17 at 16:26
• This answer is ludicrous. You don't need multiple people to make mistakes you'd like to revert, or want to keep track of change history, or try out experiments on a separate branch. – BlueRaja - Danny Pflughoeft Sep 11 '17 at 19:28
• Perhaps I should add "teaching what a revision-control tool is really for" to my list of CS complaints here, since clearly a lot of people still don't understand this. – T.E.D. Sep 11 '17 at 21:16
• @enderland - Point is, revision control tools don't fix this (and weren't meant to). – T.E.D. Sep 11 '17 at 22:19

CS students are taught to use version control software.

I teach at a small liberal arts college, and we've taught its use in our capstone course (and sometimes others) for as far back as I can remember, at least since 2005.

A graduate's not knowing something does not necessarily imply it was not taught. Students tell me they've never seen material that I know was in the prerequisite class. I'm sure this is not unique to CS. (Students are taught proper writing in the required English 1, but they don't all use it.)

Teaching something does not guarantee that students understand it. They could have copied-and-pasted commands or relied on their teammates (or Stack Overflow.)

I don't include questions about VCS on tests, just like I don't include questions on how to use IDEs and debuggers, but that doesn't mean it isn't taught.

# It's not university-level material.

Version control can be picked up easily by one of the thousands tutorials available on the web. It's more interesting to give a course on data structures, algorithms, formal logic, mathematics... and lay a broad foundation to widen & deepen the understanding, than explaining trivial concepts like version control.

• No - just like the university won't teach you how to program monopoly, risk & yahtzee, it won't teach you how to use source control. It will teach you what you need to learn it by yourself: logical thinking, databases, modelling, programming basics, certain methodologies... it's a level of abstraction. University lays the foundations, the student is supposed to erect the building themselves. – Konerak Sep 14 '17 at 6:08
• Ad hominem attacks are counted as a fallacy in a discussion, ErikE. They don't really add any value. We actually did learn how to program (not play - I said programming monopoly in my comment above, you twisted it to playing) in university, but as an exercise to anchor the learned (theoretical) material. – Konerak Sep 14 '17 at 11:11
• @ErikE I don't think that the complement set of "university-level stuff" is "stuff that all students know already" or "stuff that is taught in high school". See also: using a graphing calculator or a word processor. – Tobia Tesan Sep 14 '17 at 12:24
• I did misread what you said, and thought you were referring to playing those games, not programming them. My apologies. Had that been your actual statement, I would stand by what I said. It was not an ad hominem attack that meant your argument was invalid because you were not an adult, but simply that anyone making such a ridiculous statement is not acting in an adult way. What I thought you were saying deserves to be called "not adult." – ErikE Sep 15 '17 at 6:55
• A serious comment then. The types of commits you make, what changes you include together, how you comment your commits, and your workflow options for collaboration and code review are integral to coding. These change how you code. I don't agree version control is an afterthought or mere application like the way you might program a game. I see developers struggle with git all the time. It's a valuable tool and, all else being equal, I would take a developer who'd learned git over one who'd learned b-trees or any other three data structures taught in college. – ErikE Sep 15 '17 at 7:00

Version control is most effective in an environment where at least one user understands it quite well. As long as you have one individual on the team that understands how to recover from a messy situation, everyone else can comfortably learn as they go. However, if one does not have such a knowledgeable individual, there may be no clear way to recover from the sorts of situations that VCS is supposed to help you with. For example, if I'm not on your team, and you come across a "Tree conflict" in Subversion, it's unlikely that anyone has bookmarked the StackExchange answer that lists each tree conflict and the series of commands which resolve it. Instead, "Tree conflict" quickly becomes "wipe out your repository and do it again."

In a commercial setting, there are typically senior developers or team leads who are actively monitoring the state of the repositories and can guide you down your path. In an academic setting, one is not so lucky.

If I were to introduce VCS to a curriculum, I would use it in the context of group projects, and I would want to make sure the VCS tools are actively maintained and used. This may call for extra effort on my part, or that of a TA (which may not be an acceptable cost). I'd say 95% of the value of VCS becomes apparent when one is working on a team, rather than on their own.

• Is it likely that anyone can find a StackExchange answer that they haven't bookmarked? – JoelFan Sep 12 '17 at 19:53

Along with the several reasons mentioned above (especially the part about educators themselves not having used version control in their learning days, and the part where it was written that version control is more of a work place concept), one more reason why we (as in universities here in India) cannot teach is because we simply don't have git server access. Its a cost that some colleges are simply unable to bear.

An alternative to that would be using an online service such as GitHub or Bitbucket (my preferred choice) which are free. However, that also does not work because internet access is either non-existent or not provided (because kids will spent time on the internet).

Perhaps the final reason why we don't use it here is because, for many students computer access and internet access at home itself is a challenge. Even if the college does provide version control access, the students cannot access it when they want to anyway.

Due to these 'infrastructure issues' code is usually carried by the student via printouts, USB pen drives or simply stored as files on their mobile phones.

• Huh? You don't need a server or Internet access to use RCS, CVS, Subversion, or git; I haven't used any others, but I assume they work fine from a pen drive too. – Peter Taylor Sep 12 '17 at 8:33
• @PeterTaylor true, e.g. .svn and .git folders can also be copied along with the project's subfolders. If revision control was heavily used in those repositories, these folders may be bigger than the project itself, but they can be completely copied to a pen drive and reused without Internet access. – Armfoot Sep 12 '17 at 15:58
• for me, version control without server access is essentially useless. hence the answer above :) It's like a car without fuel or a light bulb that won't burn when needed. Or a super hero who can no longer fly. Utterly useless. – Jay Sep 13 '17 at 4:27
• @Armfoot nitpicking: you probably want to git clone --mirror instead of copying the .git folder. – Tobia Tesan Sep 14 '17 at 12:25
• @Jay for me, version control without server access is essentially useless -- you are missing out. I'm surprised that you can't find value in having a history and being able to revert your changes alone. – Tobia Tesan Sep 14 '17 at 12:27

It depends on what you consider teaching revision control. One can learn how to use git like a glorified Dropbox in an afternoon. Even if working in groups, usually everyone just commits code directly to master with no explicit peer-reviewing or use of topic branches. If "taught" at this level then I agree with @Konerak: it is not University-level knowledge and, frankly, there's not much to learn anyway.

However, this is not how VCSs are used "in the real world" (read: Open Source Software). You see, VCS are all about facilitating asynchronous collaboration. This includes distributing code, storing history, branching and merging. But in most coursework students usually do not work on a project that is developed by people other than their friends and that will continue to exist when the semester ends. Thus, most of the advantages of using VCS are non-issues for students. Sure, they can benefit from its use, but most coursework can be completed without VCS with approximately the same amount of time and effort.

IMHO, VCS are not something that should be taught, in the sense of making it a curriculum item. It is a tool that naturally appears when students learn about "professional" development workflows and best practices. Many VCS features exist to support practices such as

• separate a stable version from development (topic branches)
• organize history and ensure each feature can be rolled back easily (rebase and squash commits)
• marking versions as release (tagging)
• accepting contributions without granting commit access (patches / Pull Requests)
• peer reviewing (patches / PRs)

These are not situations that students encounter when developing projects for the first few times. So, to wrap up, universities do not teach "real" VCS because either

1. it is hard/laborious to create courses that simulate a development workflow that actually needs them; or
2. their curriculum is directed towards graduating PhD candidates.

Computer Science projects don't bring out the true power of version control

Don't get me wrong, it's useful. But it's not as useful and vital as it is in industry.

CS projects tend to be "proof of concept" projects, with a short lifetime: after you pass the class, you don't care what becomes of it. Also, the team behind the software is relatively constant: you do a project alone, or with a few fellow students, do the project, and go separate ways.

If something goes wrong with you code and you lose it, or it gets corrupted because people are mixing in their contributions, that's bad of course. But since the project is relatively new, recovering is easier than it is in a years-old industry project. And worst case, you fail a deadline or fail the course. In industry, you could be losing a lot of money per hour.

In industry, an application has to be deployed to one or possibly multiple environments, by a team that hires and fires members, and it has to keep working for several years of development. Version control helps such a large team of diverse specialists work together, for a long term. It makes deployment far easier, and it makes it possible to roll back a version that somehow doesn't work in production, in a very short time.

So while version control is valuable in academic environments, it's far more valuable in industry.

I'd suggest that it's a flaw in contemporary version control systems that they (might) require university level training to use effectively, as opposed to implement or architect at a higher level (branching models, etc)

My degree did cover version control, but from a position of understanding design challenges and solutions in creating such a system (which provided a knowledge in how to use the chosen system as a by-product).

• I think the point is not so much that they're difficult to use as that many people struggle to get by without them without realizing that their struggles would be alleviated by simply using version control. – Kyle Strand Sep 12 '17 at 15:51

One point not mentioned in other answers is that it up until quite recently (more or less as git has arrived, which is by and large recently) it has not been easy to give students access to version control.

Subversion requires you set up a local server on your computer, SourceSafe requires a license.

And you will have to support students that have messed up their installations. This alone will take an awful lot of time from other things students have to learn.

To use version control in teaching you'll have to have a lab, where the students can go and get their problems and computers fixed. That is a cost most institutions rather not incur.

And there is the problem of teaching material. I doubt there is much available litterature for students. Most material on the net is for people who already are developers and know what version control is and it is simply to high a level for students.

• I learnt sccs in 1991, it was installed on all of the university computers. – ctrl-alt-delor Sep 12 '17 at 17:09
• Your answer rather ignores the fact that most institutions that teach CS will have one or more computer labs, with machines on which they can pre install useful software, but I can believe that using version control systems was harder in the past than currently and so many institutions will have no tradition/habit of using them. – walrus Sep 12 '17 at 17:24
• >Subversion requires you set up a local server on your computer - It can be used without one, just like git. This is how we did it at university a year or two before git was created – Nye Sep 14 '17 at 13:32

The majority of 'Version Control' actually pre-dates the Titanic, and was developed as part of Drawing Office procedures. It is only very very recently that the newer distributed version control capabilities have been developed.

Back in the day, drawings were made with India ink on kaolin and linen sheets, and were effectively more valuable than the 'old masters' artworks. If they were damaged then the product could not be built, thus great pains were taken to protect the master from damage or modification. Drawings were 'traced', and from those trace's the blue-prints were made. One would have to request changes, which would be batched up, before a 'change order' was allowed.

In those days there was only one physical master. Protection was paramount. The problems were human and physical. It was an administrative exercise.

Now we have perfect replication and high volume storage. Thus now we often use verification hashes to check if our 'master' is the same as their 'master'. And we use Merkle trees to verify the history of the modifications - Is our master properly derived from their base design (e.g. Git).

So underneath there is a lot of CS theory at work, but it's still something of an administrative exercise. It all depends on whether one is educating someone to be an academic, or a practitioner (or developing the practice..).

It's still a bit of a human problem, it's just that anyone over 30 probably still thinks the old way.

• I'm not quite sure what you're saying: do you think that as a dinosaur in my mid-30s I use kaolin and India ink? – Peter Taylor Sep 15 '17 at 10:55
• @PeterTaylor, The older we are, the more history we have embedded in our knowledge (and less the younger we are). So I do remember the smell of the blue print machine from long ago (only seen kaolin and linen in the museums;-), and I now use Git when I can. At my work site (established during WWII) our (computerised) version control system has many attributes of the older DO systems. In part I was noting that modern CS 'version control' have developed from perhaps unexpected origins - Is it still my grandfather's axe? Is this the one that cuts down trees? – Philip Oakley Sep 15 '17 at 11:20
• Welcome to CSEducators. While history isn't our main focus here it was nice to see a bit of it here. As an old person, I can agree..... wait, I forget... – Buffy Sep 15 '17 at 11:54
• @Buffy, the history helps provide the "why's" that put the "how's" into context ;-). E.g. I personally like FORTH as a language (1976-) because of it's ease of use and contrasts with other programming styles. (Knowledge of) It helps one think! – Philip Oakley Sep 15 '17 at 14:58