<h1>It's not university-level material.</h1>
<p>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 &amp; deepen the understanding, than explaining trivial concepts like version control.</p>

CC BY-SA 3.0
2017-09-14T00:00:05.900Z
If it's not university-level material, then it seems like students should already know it before attending a college programming course. Right?
ErikE
CC BY-SA 3.0
2017-09-14T06:08:35.187Z
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
CC BY-SA 3.0
2017-09-14T11:11:00.563Z
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
CC BY-SA 3.0
2017-09-14T12:24:13.327Z
@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
CC BY-SA 3.0
2017-09-15T06:55:25.103Z
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
CC BY-SA 3.0
2017-09-15T07:00:01.407Z
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
CC BY-SA 3.0
2017-09-15T07:03:30.610Z
Git rebase, splitting a commit, index editing, fixing problems like the public repo getting rewritten, recovering lost commits, solving tricky merge conflicts, rewriting or replacing a commit several commits back, and so on and so forth are super useful knowledge that CS graduates ought to be well-versed in. It's hardly like "using a word processor".
ErikE
CC BY-SA 3.0
2017-09-13T06:32:35.833Z
2017-09-13T06:32:35.833Z
2020-06-18T08:36:57.023Z
Konerak
<p>The main thing you need version control for is for <strong>group coding projects</strong>.</p>

<p>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. </p>

<p>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.</p>

<p>Typical practice back then, and I gather today as well, was to train CS students to <em>work alone</em>. 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.</p>

<p>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...</p>

CC BY-SA 3.0
2017-09-11T16:22:15.123Z
`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
CC BY-SA 3.0
2017-09-11T16:26:27.483Z
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
CC BY-SA 3.0
2017-09-11T16:31:47.323Z
@walrus - Yay! Very encouraged to hear that.
T.E.D.
CC BY-SA 3.0
2017-09-11T19:28:42.510Z
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
CC BY-SA 3.0
2017-09-11T21:11:15.387Z
@BlueRaja-DannyPflughoeft - You don't need a full-blown revision control tool to do any of that either though, and its a conspicuously heavy solution if those are the only tasks you use it for. I was doing all that stuff just fine with VMS and its [automatic edit backup version system](http://www.mcm.edu/tutorial/vaxguide.htm) before I ever heard about their revision control tool. What I **couldn't** do without it was manage simultaneous work from multiple people.
T.E.D.
CC BY-SA 3.0
2017-09-11T21:16:59.020Z
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.
CC BY-SA 3.0
2017-09-11T21:26:59.593Z
@enderland - I believe my first crack at this ever with the VMS tool kept the repository in my main working directory. Early revision control tools liked to work that way, and if you didn't like it you had to fake it out with link directories. The VMS equivalent of the "rm -rf" command would have likely deleted my repository just as easily. Remember that revision control tools are designed for controlling revisions from multiple people. If you can use it as a glorified emergency backup tool, that's nice, but it isn't its prime designed purpose.
T.E.D.
CC BY-SA 3.0
2017-09-11T21:45:12.340Z
@enderland ...today if I use git, that mistaken "rm" command will **still** delete everything I've done since my last merge push up to the master. If the "master" is in fact in my .git subdirectory because nobody else is collaborating with me, then the mistaken "rm" will delete all my code, and all history, so your "CS rite of passage" is probably quite safe.
T.E.D.
CC BY-SA 3.0
2017-09-11T22:05:13.047Z
@T.E.D. part of the rite of passage is understanding the importance of _pushing_ your code somewhere, too ;-)  This helps you in industry if you accidentally `rm -rf ~` when you have too little coffee without fully thinking when trying to delete an errantly created folder named ~ (speaking for someone else, of course).
enderland
CC BY-SA 3.0
2017-09-11T22:19:13.647Z
@enderland - Point is, revision control tools don't fix this (and weren't meant to).
T.E.D.
CC BY-SA 3.0
2017-09-11T16:14:52.120Z
2017-09-11T16:21:11.980Z
2017-09-11T16:21:11.980Z
T.E.D.
<p><strong>CS students are taught to use version control software.</strong></p>

<p>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.</p>

<p>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.)</p>

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

<p>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.</p>

CC BY-SA 3.0
2017-09-13T00:53:07.970Z
2017-09-13T01:50:20.577Z
2017-09-13T01:50:20.577Z
Ellen Spertus
<p>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."</p>

<p>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.</p>

<p>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.</p>

CC BY-SA 3.0
2017-09-12T19:53:47.273Z
Is it likely that anyone can find a StackExchange answer that they haven't bookmarked?
JoelFan
CC BY-SA 3.0
2017-09-12T19:24:32.650Z
2017-09-12T19:24:32.650Z
Cort Ammon
<p>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. </p>

<p>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). </p>

<p>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.</p>

<p>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. </p>

CC BY-SA 3.0
2017-09-12T08:33:44.283Z
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
CC BY-SA 3.0
2017-09-12T15:58:12.520Z
@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
CC BY-SA 3.0
2017-09-13T04:27:30.377Z
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
CC BY-SA 3.0
2017-09-13T14:48:05.250Z
Makes sense, but you still want to be keeping a repo in the pen drive. You have the barrier of working out how to make the workflow, but it will pay back quickly.
Sean Houlihane
CC BY-SA 3.0
2017-09-13T15:14:31.757Z
Use the pen drive as the repository storage (instead of a server) is an interesting approach. I will have to think about that if only because, as a responsible trainer, I am bound to keep my mind open for suggestions. A superhero who can no longer fly can still kick ass on the ground.
Jay
CC BY-SA 3.0
2017-09-14T12:25:18.213Z
@Armfoot nitpicking: you probably want to `git clone --mirror` instead of copying the `.git` folder.
Tobia Tesan
CC BY-SA 3.0
2017-09-14T12:27:00.247Z
@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
CC BY-SA 3.0
2017-09-14T12:42:46.670Z
Looks like I am missing out indeed. My first experience with git was at an office and yeah, it was all connected. Yet, here I am, learning stuff.
Jay
CC BY-SA 3.0
2017-09-12T06:59:34.387Z
2017-09-12T06:59:34.387Z
Jay
<p>One term that I don't see in the answers given is &quot;Software Carpentry&quot;. This is a collective name for all those skills (version control, unit testing, build systems, documentation generation) that are completely not academic, but useful for programmers of all stripes, including academic.</p>
<p>The problem is where to find place in a university curriculum to teach software carpentry. Universities are (outside of studies such as computational engineering) more concerned with research-y topics, not &quot;mere craft&quot;, so they limit the time allocated for it. Plenty of universities barely teach a decent programming language: limiting themselves to some matlab and python, never mind that the poor students may be thrown in large C/Fortran code bases in their graduate career.</p>
<p>So: source code control is &quot;beneath&quot; the CS professors; it's something the students are supposed to pick up on their own.</p>

CC BY-SA 4.0
2022-01-17T21:30:45.463Z
Is that a term of art, or is it you own? I've never heard those kinds of skills grouped together under any term.  I love it!
Ben I.
CC BY-SA 4.0
2022-01-17T21:34:46.153Z
@BenI. That term comes from Greg Wilson. See https://software-carpentry.org/ in particular https://software-carpentry.org/scf/history/ Yes, it's a great one.
Victor Eijkhout
CC BY-SA 4.0
2022-01-20T21:02:49.797Z
Another argument in favor of apprenticeship.
Scott Rowe
CC BY-SA 4.0
2022-01-17T19:02:42.673Z
2022-01-17T19:02:42.673Z
Victor Eijkhout
<p>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)</p>

<p>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). </p>

CC BY-SA 3.0
2017-09-12T15:51:01.027Z
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
CC BY-SA 4.0
2022-01-17T23:46:55.187Z
I have no idea why this answer is being downvoted.  Relevant xkcd: https://xkcd.com/1597/  Git is many things, but simple to use is not one of them.
Ben I.
CC BY-SA 3.0
2017-09-12T02:44:25.510Z
2017-09-12T02:44:25.510Z
Rich
<p>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.</p>

<p>Subversion requires you set up a local server on your computer, SourceSafe requires a license.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

CC BY-SA 3.0
2017-09-12T17:09:34.110Z
I learnt sccs in 1991, it was installed on all of the university computers.
ctrl-alt-delor
CC BY-SA 3.0
2017-09-12T17:24:34.173Z
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
CC BY-SA 3.0
2017-09-14T13:32:41.887Z
>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
CC BY-SA 4.0
2022-01-18T03:44:36.380Z
@walrus That's not the case any more.  Most computer science programs are in lower level schools than colleges at this point, if only because they are being mandated by laws around the world, and such schools simply outnumber colleges by astronomical margins.  Not having labs is, indeed, a huge problem for teaching VCSs at lower levels.
Ben I.
CC BY-SA 3.0
2017-09-12T16:54:36.757Z
2017-09-12T16:54:36.757Z
Bent
<p>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.</p>

<p>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.</p>

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

<p>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). </p>

<p>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..).</p>

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

CC BY-SA 3.0
2017-09-15T10:55:29.160Z
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
CC BY-SA 3.0
2017-09-15T11:20:58.733Z
@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
CC BY-SA 3.0
2017-09-15T11:54:07.410Z
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
CC BY-SA 3.0
2017-09-15T14:58:47.613Z
@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
CC BY-SA 3.0
2017-09-15T10:47:48.413Z
2017-09-15T10:47:48.413Z
Philip Oakley
<p><strong>Computer Science projects don't bring out the true power of version control</strong></p>

<p>Don't get me wrong, it's useful. But it's not <em>as</em> useful and vital as it is in industry.</p>

<p>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.</p>

<p>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 <em>lot</em> of money <em>per hour</em>.</p>

<p>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.</p>

<p>So while version control is valuable in academic environments, it's <em>far more</em> valuable in industry.</p>

CC BY-SA 4.0
2020-01-02T15:23:07.923Z
2020-01-02T15:23:07.923Z
ObscureOwl
<p>It depends on what you consider <em>teaching</em> revision control. One can learn how to use <em>git</em> like a glorified Dropbox in an afternoon. Even if working in groups, usually everyone just commits code directly to <code>master</code> 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.</p>

<p>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 <strong>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.</strong> 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. </p>

<p>IMHO, VCS are not something that should be <em>taught</em>, 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 </p>

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

<p>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</p>

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

CC BY-SA 4.0
2019-12-31T19:33:17.780Z
2019-12-31T19:33:17.780Z
igordsm
<p>I suspect it's a combination of several factors:</p>

<ol>
<li>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).</li>
<li><p>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.</p>

<p>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.</p></li>
<li><p>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. </p>

<p>(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.)</p></li>
<li>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.)</li>
</ol>

<p>So basically, it's material that's difficult to fully cover (where the subset you <em>can</em> 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. </p>

<p>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.</p>

<p>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.</p>

CC BY-SA 3.0
2017-09-11T17:41:30.130Z
This answer seems to mainly address point b) from the question. Do you have any thoughts on why some universities ignore the benefits to them apart from inertia and lack of time (the latter of which I struggle to believe is a real issue in a 3 or 4 year degree).
walrus
CC BY-SA 3.0
2017-09-11T18:02:24.123Z
@walrus -- I think it's less that you're ignoring the benefits. Rather, it's more that there are just so many things that could be teaching and it's hard to pick. An undergraduate degree has time to cover only a tiny fraction of computer science -- that's a part of why we have masters degrees and PhD programs, after all (and even those can only cover a small fraction of what's out there)..
Michael0x2a
CC BY-SA 3.0
2017-09-11T18:02:57.567Z
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
CC BY-SA 3.0
2017-09-11T22:02:03.843Z
that's one way of looking at it. I suppose I'm surprised that you'd struggle to fit a course with only a couple of hours' content in, especially considering some of the things that (both my and other) courses do find time to include.

Regarding the university getting the benefit; I can see that it could definitely be more trouble than it's worth, but I can also see that it could make certain things a lot easier to administer for the university.
walrus
CC BY-SA 3.0
2017-09-11T22:09:27.693Z
@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
CC BY-SA 3.0
2017-09-12T00:16:19.367Z
"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
CC BY-SA 3.0
2017-09-12T01:32:01.340Z
@Kevin: I suppose it might depend on which VCS you're learning -- there are certainly some quirky ones out there. But I genuinely do think that a CS graduate shouldn't find it too hard to pick up something like Git by working through something like [LearnGitBranching](http://learngitbranching.js.org/): after all, Git basically boils down to a tool for manipulating DAGs, and graph manipulation should be the sort of thing that's extensively covered both explicitly and implicitly in a decent CS curriculum. The other best practices stuff is only a google search or two away with the right query.
Michael0x2a
CC BY-SA 3.0
2017-09-12T14:06:04.173Z
I second @Kevin's comment. See e.g. [this](https://cseducators.stackexchange.com/q/2897/735) or [this](https://softwareengineering.stackexchange.com/q/351607/78464) 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](https://git-scm.com/book/en/v2), and that book doesn't even explain *how* Git works, a topic which the same author wrote [a separate 120 page book](https://github.com/pluralsight/git-internals-pdf) on.
JBentley
CC BY-SA 3.0
2017-09-12T16:24:05.967Z
@Kevin I partly disagree with you.  I think that it's very easy how to learn how to use Git in a single-user environment, where you are working out of master, never branch, and never merge.  (Which describes how you would probably use version control for most school assignments)  I agree though, that Git gets very complex very fast, as soon as you involve branching and merging.  That when you run into this: http://justinhileman.info/article/git-pretty/
Patrick M
CC BY-SA 3.0
2017-09-12T17:45:21.130Z
@JBentley sorry, I still disagree. I do think Git is often taught poorly, but don't think it's *inherently* hard to learn. All you need to know is that Git is a tool for manipulating DAGs -- you can infer what's possible and how to do it on-the-fly based on just this and a little googling without needing to read a ~600 page manual. For example, if you didn't know about something like `rebase -i`, you'd still be able to easily infer the existence of this command: you can rearrange nodes in a DAG, so Git certainly must support such an operation. You can then google/read the book to get details.
Michael0x2a
CC BY-SA 3.0
2017-09-12T17:46:10.717Z
That said, I do agree that if you try and learn Git without knowing about graphs or using a tutorial that doesn't emphasize the DAG that learning to use Git would be challenging: without understanding the underlying model, Git would be very cryptic. Unfortunately, many tutorials seem to de-emphasize the DAG (possibly to target beginners?) and focus on teaching specific commands instead, which is probably why people find Git challenging to pick up. That fact that Git commands are often named unintuitively only compounds the problem for people who learned this way.
Michael0x2a
CC BY-SA 3.0
2017-09-12T19:17:57.713Z
@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
CC BY-SA 3.0
2017-09-12T22:35:54.270Z
I think another thing here that has not been touched on is that command line Git is not the only version control method out there. I would bet that if one can grasp fundamental data structures, one can figure out a version control system at their leisure.
Tim
CC BY-SA 3.0
2017-09-13T21:35:25.030Z
The challenge of finding good tutorials on a subject is the most compelling justification for universities even existing.
Kevin Krumwiede
CC BY-SA 4.0
2019-03-18T01:09:34.690Z
I think the notion that you can (or should be able to) teach yourself a VCS has some validity - <ironic>it's mostly how I learned all of the ones that I've used</ironic>. But that only makes me think that it should most definitely included in the curriculum - teaching yourself is a valuable, and transferable, CS skill and VCS is a skill that would be widely useful in a CS program. Maybe do a brief explanation of the rationale and point students at a variety of good tutorials and offer a few lab sessions? Then adjust your curriculum so students appreciate having the skill...
dlu
CC BY-SA 3.0
2017-09-11T15:49:18.187Z
2017-09-14T16:21:36.993Z
2017-09-14T16:21:36.993Z
Michael0x2a
<p>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...</p>

<p>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. </p>

<p>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.</p>

CC BY-SA 3.0
2017-09-11T18:26:59.563Z
Are people still using `rcs`?
ctrl-alt-delor
CC BY-SA 3.0
2017-09-11T18:36:50.680Z
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
CC BY-SA 3.0
2017-09-11T18:38:35.820Z
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.
CC BY-SA 3.0
2017-09-12T17:18:01.703Z
@ctrl-alt-delor Yes, with a [modern wrapper](http://www.catb.org/esr/src/).
CL.
CC BY-SA 3.0
2017-09-11T18:05:03.110Z
2017-09-11T18:05:03.110Z
Sean Houlihane
<h1>Teaching revision control as part of CS course.</h1>
<h2>Against</h2>
<p>Revision control is not a computer science thing, it has nothing to do with computer science. Though it is a software engineering tool.</p>
<h2>For</h2>
<p><strong>Everybody</strong> 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.</p>
<hr />
<p>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).</p>

CC BY-SA 3.0
2017-09-11T22:07:52.553Z
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
CC BY-SA 3.0
2017-09-12T19:51:27.340Z
There are tools that can diff MS-Word files, which can be plugged into your version control system
JoelFan
CC BY-SA 3.0
2017-09-12T19:53:47.263Z
@JoelFan I would be interested in knowing what they are. Can they also merge?
ctrl-alt-delor
CC BY-SA 3.0
2017-09-12T20:03:02.733Z
@ctrl-alt-delor, http://blog.martinfenner.org/2014/08/25/using-microsoft-word-with-git/
JoelFan
CC BY-SA 3.0
2017-09-12T20:21:04.580Z
@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
CC BY-SA 3.0
2017-09-12T21:15:10.917Z
I think it's a mistake to say revision control is  "computer engineering" topic. Revision control should be thought of as an essential tool for any area of study/work that deals with preparing files using a computer. And even if you won't be doing it using a computer, the same principles should be learned for preparing creative works by hand - organizing and filing different revisions you went through (rough drafts, sketchbook sketches, recordings while preparing a song or a speech, etc.) - because it's how you study and improve your own processes.
R.. GitHub STOP HELPING ICE
CC BY-SA 3.0
2017-09-12T21:16:45.810Z
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
CC BY-SA 4.0
2019-03-18T00:58:46.090Z
Maybe revision control isn't a CS thing, but collaboration is, code review is, and so is testing. I'd argue that revision control is essential to all of those activities and the ability to engage productively in those activities is often looked for in interviews.
dlu
CC BY-SA 3.0
2017-09-11T18:35:58.270Z
2017-09-13T07:36:33.680Z
2020-06-18T08:36:57.023Z
ctrl-alt-delor
<p>In the answers to <a href="https://cseducators.stackexchange.com/questions/3572/what-does-a-person-with-an-undergraduate-degree-in-cs-still-need-to-learn-to-be/3574#3574">this question</a>, 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.</p>

<p>This surprised me, because on my CS* course we started using revision control (git) on <em>literally</em> 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.</p>

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

<p>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.</p>

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

CC BY-SA 3.0
2017-09-13T11:15:25.213Z
Comments are not for extended discussion; this conversation has been [moved to chat](http://chat.stackexchange.com/rooms/65527/discussion-on-question-by-walrus-why-dont-more-universities-teach-revision-cont).
thesecretmaster
CC BY-SA 3.0
2017-09-13T23:56:31.933Z
Do you mean *version* control?
ErikE
CC BY-SA 3.0
2017-09-14T08:53:40.230Z
@ErikE: One of those terms not worth being nitpicky about ;) https://stackoverflow.com/questions/1056912/source-control-vs-revision-control
Sebastian Mach
CC BY-SA 3.0
2017-09-14T10:13:06.317Z
For the same reason that mechanical engineers never have to pick up a screwdriver.
J...
CC BY-SA 3.0
2017-09-14T11:46:37.490Z
Why Excel isn't thought in CS?
Calculator Science
CC BY-SA 3.0
2017-09-14T12:19:18.143Z
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
CC BY-SA 3.0
2017-09-14T13:44:54.240Z
@CalculatorScience Because there are more intuitive functional languages available.
JAB
CC BY-SA 3.0
2017-09-14T13:46:18.577Z
@TobiaTesan Probably because it's assumed those skills will have been developed earlier in general education. I had classes in middle school about how to type properly (though I'd already developed touch typing skills by that point from personal use). I don't think most grade schools teach how to use version control (yet).
JAB
CC BY-SA 3.0
2017-09-14T13:51:58.040Z
@TobiaTesan that strikes me as a bit of a straw man, really.
walrus
CC BY-SA 3.0
2017-09-14T14:14:50.450Z
@JAB I have never heard of typing classes in high school where I come from, but you can replace that with any practical skill of your choice that happens to be relevant in day-to-day university and work life and is not taught in general education. My point is that at the end of the day, there is a plethora of practical skills and mechanical tools you end up learning how to use on your own. Besides it being impractical to set aside more than an epsilon of class time for Word 101, Google 101, Emacs 101, etc...  I am not sure that teaching the use of standard tools is University's main job.
Tobia Tesan
CC BY-SA 3.0
2017-09-14T14:23:40.627Z
@walrus I did say "extreme", and it was an exaggeration on purpose - but why does it strike you as a straw man? I believe therein lies a possible answer to your question.
Tobia Tesan
CC BY-SA 3.0
2017-09-14T15:06:51.313Z
@TobiaTesan, it struck me as a straw man because it is both extreme and *not equivalent* - as JAB says it's a skill that you can reasonably assume students to have learned before university.
walrus
CC BY-SA 3.0
2017-09-16T08:07:19.653Z
Very well, you can indeed assume students who graduate from high school know how to use a graphing calculator or Excel. But in high school they don't have classes on how to use a graphing calculator or Excel and certainly middle school children don't know their way around the things, so how do they learn? It's just another example of a handy tool that people can and eventually *will* learn to use on their own by R'ing the good ol' FM, if you get what I mean. Excel is to high school what a VCS or an IDE is to college.  At least that's my humble point of view: it's not the University's job.
Tobia Tesan
CC BY-SA 4.0
2022-01-17T22:58:24.620Z
@ErikE OP mentioned `git` so revision control, not version control.
ctrl-alt-delor
CC BY-SA 4.0
2022-01-18T21:18:32.507Z
@ctrl-alt-delor That seems a really subtle distinction that isn't necessary. Version control is an umbrella term that covers more than just `git`. In any case, it's unimportant, and if people want to be picky and call it "revision control" then they are welcome to.
ErikE
CC BY-SA 4.0
2022-01-21T09:58:24.180Z
In all honesty this was a dull thing to argue about five years ago and it's not got any more interesting; if you really want to see why the question refers to revision control not version control have a look at the chat.
walrus
CC BY-SA 4.0
2022-01-23T21:26:53.853Z
@ErikE I only made the distinction between version control and revision control. Because you asked "Do you mean version control?" (2nd comment in this thread). The distinction is considerable, but as so many people both names to mean revision control, it is unreliable to make a distinction. You are correct revision control is often used as part of version control, but it can be used without it (I don't recommend it, but only because I don't recommend not using revision control)
ctrl-alt-delor
CC BY-SA 4.0
2022-01-24T22:44:55.687Z
@ctrl-alt-delor Thanks for explaining, but I really don't want to argue.
ErikE
<revision-control>
Why don't more universities teach revision control?
# Why don't more universities teach revision control?

(Asked by: username_0 on 2017-09-11)

In the answers to [this question](https://cseducators.stackexchange.com/questions/3572/what-does-a-person-with-an-undergraduate-degree-in-cs-still-need-to-learn-to-be/3574#3574), 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.

**Tags:** revision-control

> **Comments:**
> **username_1**: Comments are not for extended discussion; this conversation has been [moved to chat](http://chat.stackexchange.com/rooms/65527/discussion-on-question-by-username_0-why-dont-more-universities-teach-revision-cont).  
> **username_2**: Do you mean *version* control?  
> **username_3**: @username_2: One of those terms not worth being nitpicky about ;) https://stackoverflow.com/questions/1056912/source-control-vs-revision-control  
> **username_4**: For the same reason that mechanical engineers never have to pick up a screwdriver.  
> **username_5**: Why Excel isn't thought in CS?  
> **username_6**: 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)?  
> **username_7**: @CalculatorScience Because there are more intuitive functional languages available.  
> **username_7**: @TobiaTesan Probably because it's assumed those skills will have been developed earlier in general education. I had classes in middle school about how to type properly (though I'd already developed touch typing skills by that point from personal use). I don't think most grade schools teach how to use version control (yet).  
> **username_0**: @TobiaTesan that strikes me as a bit of a straw man, really.  
> **username_6**: @username_7 I have never heard of typing classes in high school where I come from, but you can replace that with any practical skill of your choice that happens to be relevant in day-to-day university and work life and is not taught in general education. My point is that at the end of the day, there is a plethora of practical skills and mechanical tools you end up learning how to use on your own. Besides it being impractical to set aside more than an epsilon of class time for Word 101, Google 101, Emacs 101, etc...  I am not sure that teaching the use of standard tools is University's main job.  
> **username_6**: @username_0 I did say "extreme", and it was an exaggeration on purpose - but why does it strike you as a straw man? I believe therein lies a possible answer to your question.  
> **username_0**: @TobiaTesan, it struck me as a straw man because it is both extreme and *not equivalent* - as username_7 says it's a skill that you can reasonably assume students to have learned before university.  
> **username_6**: Very well, you can indeed assume students who graduate from high school know how to use a graphing calculator or Excel. But in high school they don't have classes on how to use a graphing calculator or Excel and certainly middle school children don't know their way around the things, so how do they learn? It's just another example of a handy tool that people can and eventually *will* learn to use on their own by R'ing the good ol' FM, if you get what I mean. Excel is to high school what a VCS or an IDE is to college.  At least that's my humble point of view: it's not the University's job.  
> **username_8**: @username_2 OP mentioned `git` so revision control, not version control.  
> **username_2**: @username_8 That seems a really subtle distinction that isn't necessary. Version control is an umbrella term that covers more than just `git`. In any case, it's unimportant, and if people want to be picky and call it "revision control" then they are welcome to.  
> **username_0**: In all honesty this was a dull thing to argue about five years ago and it's not got any more interesting; if you really want to see why the question refers to revision control not version control have a look at the chat.  
> **username_8**: @username_2 I only made the distinction between version control and revision control. Because you asked "Do you mean version control?" (2nd comment in this thread). The distinction is considerable, but as so many people both names to mean revision control, it is unreliable to make a distinction. You are correct revision control is often used as part of version control, but it can be used without it (I don't recommend it, but only because I don't recommend not using revision control)  
> **username_2**: @username_8 Thanks for explaining, but I really don't want to argue.  

---

## 14 answers

### Answer by username_31 on 2017-09-11. Score: 30 | Accepted answer

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.

> **Comments:**
> **username_0**: This answer seems to mainly address point b) from the question. Do you have any thoughts on why some universities ignore the benefits to them apart from inertia and lack of time (the latter of which I struggle to believe is a real issue in a 3 or 4 year degree).  
> **username_31**: @username_0 -- I think it's less that you're ignoring the benefits. Rather, it's more that there are just so many things that could be teaching and it's hard to pick. An undergraduate degree has time to cover only a tiny fraction of computer science -- that's a part of why we have masters degrees and PhD programs, after all (and even those can only cover a small fraction of what's out there)..  
> **username_31**: 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.  
> **username_0**: that's one way of looking at it. I suppose I'm surprised that you'd struggle to fit a course with only a couple of hours' content in, especially considering some of the things that (both my and other) courses do find time to include.  Regarding the university getting the benefit; I can see that it could definitely be more trouble than it's worth, but I can also see that it could make certain things a lot easier to administer for the university.  
> **username_31**: @username_0 -- 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.  
> **username_32**: "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.  
> **username_31**: @username_32: I suppose it might depend on which VCS you're learning -- there are certainly some quirky ones out there. But I genuinely do think that a CS graduate shouldn't find it too hard to pick up something like Git by working through something like [LearnGitBranching](http://learngitbranching.js.org/): after all, Git basically boils down to a tool for manipulating DAGs, and graph manipulation should be the sort of thing that's extensively covered both explicitly and implicitly in a decent CS curriculum. The other best practices stuff is only a google search or two away with the right query.  
> **username_33**: I second @username_32's comment. See e.g. [this](https://cseducators.stackexchange.com/q/2897/735) or [this](https://softwareengineering.stackexchange.com/q/351607/78464) 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](https://git-scm.com/book/en/v2), and that book doesn't even explain *how* Git works, a topic which the same author wrote [a separate 120 page book](https://github.com/pluralsight/git-internals-pdf) on.  
> **username_34**: @username_32 I partly disagree with you.  I think that it's very easy how to learn how to use Git in a single-user environment, where you are working out of master, never branch, and never merge.  (Which describes how you would probably use version control for most school assignments)  I agree though, that Git gets very complex very fast, as soon as you involve branching and merging.  That when you run into this: http://justinhileman.info/article/git-pretty/  
> **username_31**: @Jusername_25ley sorry, I still disagree. I do think Git is often taught poorly, but don't think it's *inherently* hard to learn. All you need to know is that Git is a tool for manipulating DAGs -- you can infer what's possible and how to do it on-the-fly based on just this and a little googling without needing to read a ~600 page manual. For example, if you didn't know about something like `rebase -i`, you'd still be able to easily infer the existence of this command: you can rearrange nodes in a DAG, so Git certainly must support such an operation. You can then google/read the book to get details.  
> **username_31**: That said, I do agree that if you try and learn Git without knowing about graphs or using a tutorial that doesn't emphasize the DAG that learning to use Git would be challenging: without understanding the underlying model, Git would be very cryptic. Unfortunately, many tutorials seem to de-emphasize the DAG (possibly to target beginners?) and focus on teaching specific commands instead, which is probably why people find Git challenging to pick up. That fact that Git commands are often named unintuitively only compounds the problem for people who learned this way.  
> **username_14**: @username_31 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.  
> **username_35**: I think another thing here that has not been touched on is that command line Git is not the only version control method out there. I would bet that if one can grasp fundamental data structures, one can figure out a version control system at their leisure.  
> **username_36**: The challenge of finding good tutorials on a subject is the most compelling justification for universities even existing.  
> **username_37**: I think the notion that you can (or should be able to) teach yourself a VCS has some validity - <ironic>it's mostly how I learned all of the ones that I've used</ironic>. But that only makes me think that it should most definitely included in the curriculum - teaching yourself is a valuable, and transferable, CS skill and VCS is a skill that would be widely useful in a CS program. Maybe do a brief explanation of the rationale and point students at a variety of good tutorials and offer a few lab sessions? Then adjust your curriculum so students appreciate having the skill...  

---

### Answer by username_8 on 2017-09-11. Score: 15

# 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).

> **Comments:**
> **username_0**: 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.  
> **username_15**: There are tools that can diff MS-Word files, which can be plugged into your version control system  
> **username_8**: @username_15 I would be interested in knowing what they are. Can they also merge?  
> **username_15**: @username_8, http://blog.martinfenner.org/2014/08/25/using-microsoft-word-with-git/  
> **username_8**: @username_15 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.  
> **username_40**: I think it's a mistake to say revision control is  "computer engineering" topic. Revision control should be thought of as an essential tool for any area of study/work that deals with preparing files using a computer. And even if you won't be doing it using a computer, the same principles should be learned for preparing creative works by hand - organizing and filing different revisions you went through (rough drafts, sketchbook sketches, recordings while preparing a song or a speech, etc.) - because it's how you study and improve your own processes.  
> **username_40**: 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.  
> **username_37**: Maybe revision control isn't a CS thing, but collaboration is, code review is, and so is testing. I'd argue that revision control is essential to all of those activities and the ability to engage productively in those activities is often looked for in interviews.  

---

### Answer by username_19 on 2017-09-11. Score: 12

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.

> **Comments:**
> **username_8**: Are people still using `rcs`?  
> **username_19**: 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.  
> **username_38**: 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.  
> **username_39**: @username_8 Yes, with a [modern wrapper](http://www.catb.org/esr/src/).  

---

### Answer by username_9 on 2017-09-13. Score: 6

# 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.

> **Comments:**
> **username_2**: If it's not university-level material, then it seems like students should already know it before attending a college programming course. Right?  
> **username_9**: 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.  
> **username_9**: Ad hominem attacks are counted as a fallacy in a discussion, username_2. 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.  
> **username_6**: @username_2 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.  
> **username_2**: 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."  
> **username_2**: 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.  
> **username_2**: Git rebase, splitting a commit, index editing, fixing problems like the public repo getting rewritten, recovering lost commits, solving tricky merge conflicts, rewriting or replacing a commit several commits back, and so on and so forth are super useful knowledge that CS graduates ought to be well-versed in. It's hardly like "using a word processor".  

---

### Answer by username_10 on 2017-09-11. Score: 6

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...

> **Comments:**
> **username_11**: `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.  
> **username_0**: 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.  
> **username_10**: @username_0 - Yay! Very encouraged to hear that.  
> **username_12**: 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.  
> **username_10**: @BlueRaja-DannyPflughoeft - You don't need a full-blown revision control tool to do any of that either though, and its a conspicuously heavy solution if those are the only tasks you use it for. I was doing all that stuff just fine with VMS and its [automatic edit backup version system](http://www.mcm.edu/tutorial/vaxguide.htm) before I ever heard about their revision control tool. What I **couldn't** do without it was manage simultaneous work from multiple people.  
> **username_10**: 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.  
> **username_10**: @username_11 - I believe my first crack at this ever with the VMS tool kept the repository in my main working directory. Early revision control tools liked to work that way, and if you didn't like it you had to fake it out with link directories. The VMS equivalent of the "rm -rf" command would have likely deleted my repository just as easily. Remember that revision control tools are designed for controlling revisions from multiple people. If you can use it as a glorified emergency backup tool, that's nice, but it isn't its prime designed purpose.  
> **username_10**: @username_11 ...today if I use git, that mistaken "rm" command will **still** delete everything I've done since my last merge push up to the master. If the "master" is in fact in my .git subdirectory because nobody else is collaborating with me, then the mistaken "rm" will delete all my code, and all history, so your "CS rite of passage" is probably quite safe.  
> **username_11**: @username_10 part of the rite of passage is understanding the importance of _pushing_ your code somewhere, too ;-)  This helps you in industry if you accidentally `rm -rf ~` when you have too little coffee without fully thinking when trying to delete an errantly created folder named ~ (speaking for someone else, of course).  
> **username_10**: @username_11 - Point is, revision control tools don't fix this (and weren't meant to).  

---

### Answer by username_13 on 2017-09-13. Score: 4

**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.


---

### Answer by username_14 on 2017-09-12. Score: 2

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.

> **Comments:**
> **username_15**: Is it likely that anyone can find a StackExchange answer that they haven't bookmarked?  

---

### Answer by username_16 on 2017-09-12. Score: 1

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.

> **Comments:**
> **username_17**: 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.  
> **username_18**: @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.  
> **username_16**: 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.  
> **username_19**: Makes sense, but you still want to be keeping a repo in the pen drive. You have the barrier of working out how to make the workflow, but it will pay back quickly.  
> **username_16**: Use the pen drive as the repository storage (instead of a server) is an interesting approach. I will have to think about that if only because, as a responsible trainer, I am bound to keep my mind open for suggestions. A superhero who can no longer fly can still kick ass on the ground.  
> **username_6**: @username_18 nitpicking: you probably want to `git clone --mirror` instead of copying the `.git` folder.  
> **username_6**: @username_16 `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.  
> **username_16**: Looks like I am missing out indeed. My first experience with git was at an office and yeah, it was all connected. Yet, here I am, learning stuff.  

---

### Answer by username_29 on 2020-01-02. Score: 1

**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.


---

### Answer by username_30 on 2019-12-31. Score: 1

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 @username_9: 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.


---

### Answer by username_20 on 2022-01-17. Score: 0

One term that I don't see in the answers given is "Software Carpentry". This is a collective name for all those skills (version control, unit testing, build systems, documentation generation) that are completely not academic, but useful for programmers of all stripes, including academic.

The problem is where to find place in a university curriculum to teach software carpentry. Universities are (outside of studies such as computational engineering) more concerned with research-y topics, not "mere craft", so they limit the time allocated for it. Plenty of universities barely teach a decent programming language: limiting themselves to some matlab and python, never mind that the poor students may be thrown in large C/Fortran code bases in their graduate career.

So: source code control is "beneath" the CS professors; it's something the students are supposed to pick up on their own.

> **Comments:**
> **username_21**: Is that a term of art, or is it you own? I've never heard those kinds of skills grouped together under any term.  I love it!  
> **username_20**: @BenI. That term comes from Greg Wilson. See https://software-carpentry.org/ in particular https://software-carpentry.org/scf/history/ Yes, it's a great one.  
> **username_22**: Another argument in favor of apprenticeship.  

---

### Answer by username_23 on 2017-09-12. Score: 0

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).

> **Comments:**
> **username_24**: 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.  
> **username_21**: I have no idea why this answer is being downvoted.  Relevant xkcd: https://xkcd.com/1597/  Git is many things, but simple to use is not one of them.  

---

### Answer by username_25 on 2017-09-12. Score: 0

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.

> **Comments:**
> **username_8**: I learnt sccs in 1991, it was installed on all of the university computers.  
> **username_0**: 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.  
> **username_26**: >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  
> **username_21**: @username_0 That's not the case any more.  Most computer science programs are in lower level schools than colleges at this point, if only because they are being mandated by laws around the world, and such schools simply outnumber colleges by astronomical margins.  Not having labs is, indeed, a huge problem for teaching VCSs at lower levels.  

---

### Answer by username_27 on 2017-09-15. Score: -2

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.

> **Comments:**
> **username_17**: 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?  
> **username_27**: @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?  
> **username_28**: 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...  
> **username_27**: @username_28, 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!  

---

