In the words of Andrew Clay Shafer, “In software development, version control is the foundation of every other Agile technical practice.” (Allspaw & Robbins, 2010). Yet, 57% of CS curricula does not provide practical exposure to it. (Betz)

How can I teach the use of source code control as part of an introductory CS class?

To put it another way: How can we introduce source code control early in the curriculum?

  • $\begingroup$ Note you are asking about revision-control not version-control. Yes they are different things. $\endgroup$ May 28, 2017 at 22:53
  • $\begingroup$ @ctrl-alt-delor Wikipedia says that they are the same thing: en.wikipedia.org/wiki/Version_control $\endgroup$ Sep 12, 2017 at 22:23
  • $\begingroup$ An introductory class may be the only exposure some students ever get to CS. There are so many interesting, inspiring and cross-subject topics to cover in such little time. If a student doesn't end up sticking with CS, was investing time in a specific VCS worth it? $\endgroup$
    – Tim
    Sep 12, 2017 at 23:03
  • $\begingroup$ @KevinWorkman Wikipedia is good, real good. However is is not always correct. There is a difference, but in seems that most people do not make it. Like the difference between noise and sound, or heat and temperature. No one else on this site, is making the distinction, so I would not worry too much. $\endgroup$ Sep 13, 2017 at 7:40
  • $\begingroup$ As revision control is useful for everyone, not just CS students. It could be introduced outside of a programming context, very early on. see also cseducators.stackexchange.com/a/3601/204 $\endgroup$ Sep 13, 2017 at 7:45

2 Answers 2


There are quite a few solutions which allow you to make a VCS part of your teaching.

For example, GitHub Classroom allows you to create assignments with some starter code, then invite your students to work on it and submit their changes through Git. They provide a promotional video here, which shows the workflow with it.

Scaffolding Version Control into the Computer Science Curriculum states:

VCS and other professional tools are often introduced later in the educational curriculum, possibly in a software engineering course, generally a second-year or later course, and may not be reinforced through repetition and application in later classes. This is unfortunate, because powerful tools such as VCS can also be difficult for new users and especially those new to programming and software in general. The power and flexibility of new distributed VCS can make them especially challenging, unfriendly, and distracting for students already fully engaged in developing core competencies required in the computer science curriculum.

They propose GitSubmit as a helpful solution here, describing it as "A Custom Environment for Introducing VCS to Novice Developers". Clearly, it's helpful here to introduce VCS as soon as possible, to avoid the issues described later in the paper, where higher level students have virtually no experience of using a VCS, despite its importance in industry.

For the pedagogical challenges, the presentation Challenges and Confusions in Learning Version Control with Git seems interesting. They conclude:

  • Introduce authentic/relevant use cases to motivate the use and learning of the system
  • Authentic practical courses cause students to see the value of VCSs
  • However, use VCSs throughout the curriculum, as, for instance, limited resources available during authentic project courses may limit how the system is adopted

(1) We start out by using a repository for dissemination. That is, students retrieve projects via the version control system. This familiarizes them with basic tool interaction helps get the kinks out in a low-stakes way.

(2) Then we introduce the use of version control for saving incremental stages of a project. The motivation is straightforward once students realize they can "back out" changes they've made. Students also seem to like seeing "differences" between versions.

(3) Having established that foundation, students use the version control system to facilitate work on projects in groups. We establish a few conventions to ease the transition, such as "check in often" and "never break the build". Groups are typically of size 3 in my single semester intro course. (Students have already programmed in pairs prior to group work; but that was done in "pair programming" style using single systems.)

We have had good success using the BlueJ integrated learning/development environment which incorporates support for both Git and Subversion.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.