# on-What are pre-requisites for teaching version control to a high school CS class?

I'm interested in introducing version control to a HS CS class, and was considering starting with Github since it's a fairly standard tool used by developers.

What are pre-requisites for understanding version control that I should make sure students master first?

Any suggestions on other ways to introduce this topic to students are definitely welcome!

The biggest one for me would be a reason to use version control. When you're writing small lab assignments, version control probably isn't worth all that much. It's when they get to a point where projects become larger than a handful of methods, or when you're working on separate pieces of a larger project with partners that it becomes useful.

Version control, specifically Git and GitHub, is definitely on my list of new topics to add to my 2nd year course next year. My students are doing collaborative projects right now and it's painful to watch them email code back and forth.

• Does 'having lost hours of coding through not using backups' count as a reason? – Sean Houlihane May 23 '17 at 17:36
• Yeah, probably should :) I've certainly had students accidentally delete things they're working on. – Ryan Nutt May 23 '17 at 17:40
• +1 on the reason. A big motivation for some of my students is the easy ability to access their code from home. And when collaborative projects come along many will appreciate having tools to support parallel development (my students want it to work like Google Docs with partners typing in the same file at the same time - while at the same time resisting pair programming, I'd love a way to let them try that without a lot of overhead...). – dlu Mar 18 '19 at 3:02

Version control and the associated tool addresses the following (at least)

• Backups (for when you lost or deleted something)
• History of changes (for when you made a mistake and need to go back)
• Collaborative working (sharing and merging)
• Reviewing
• Bug fixing and development on different branches

As I've written these, I think they're roughly in order of being less obvious or harder to grasp. Everyone is familiar with the need to keep a backup of an essay (we hope) but the idea of going back to look at how something was written at the start of last week's lesson is rather more unique to writing code.

The most obvious prerequisite would be to get to the stage where rather than starting to write a program from scratch, it's better to take something old and re-purpose it. This is roughly the same point where you start to care about loosing something (to start with, code gets better if you write it, throw away and start from scratch again).

Although it's slightly tangential, I would also say it is better to talk about review and collaboration before introducing version control.

I don't think it's as important to be in a position (from the start) to need to explain about switching between different branches, cherry picking, etc. A lot of the really useful ideas come from the head, logs and diffs.

# The pre-requisits

The only pre-requisites to using a computerised revision control system are:

• Use of a computer.
• Use of a computer to, create some artefact (e.g. document), and to then improve on this artefact (create multiple revisions).

However It may be possible to teach a non-computerised revision control system.

# What to revision control

The artefacts do not need to be source code. We often mix up revision-control with source-control. However revision control can be used for so much more.

You can use revision control for every file in your home directory (I also revision control /etc). However to get the best value from it, you will need a good diff tool for each file type. Thus making Microsoft's Office documents not a good choice.

Therefore it may be better to start with some other artefacts, that are not programs.

# Which tool.

There are many revision control tools. Three of the most powerful/popular are git, mercurial, and subversion. The tool that you start with, will make a large difference to the learning.

• git (git): very powerful, distributed repositories, very hard to use/learn, flavour of the month, free repo hosting service available.
• mercurial (hg): very powerful, distributed repositories, easy to use/learn, similar to git, free repo hosting service available.
• tourtoisehg: a graphical tool that integrated mercurial with the file explores, and other graphical tools, for Gnu/Linux and Microsoft's Windows.
• subversion (svn): a slightly older tool, very powerful, centralised repository, supports locking where needed, makes it better for non-mergable documents, easy to use/learn.
• tourtoisesvn: a graphical tool that integrated subversion with the file explores, and other graphical tools, for Gnu/Linux and Microsoft's Windows.