Since 2010, I teach C++ about 25 hours per year at ENSAE engineering school. During a short period we have to teach the students, with few computer science background, the complex concept of C++ (pointers, dynamic memory management, virtuality, templates etc.). The objective is to give them the basic material to be autonomous while they will be building their own C++ project during the second semester. This year we decided to sacrifice a little part of the core C++ teaching to have one lesson and a practical class dedicated to source control. Indeed, we have seen too many students struggling with sharing code on USB drives or via emails. Moreover, we do believe that this is something that a student should know before getting into any professional life involving code. To my point of view, source control is entirely a part of the software development process and could not be avoided anymore.
The source control that we decided to retain is git. Even if we do believe that SVN would suffice for the quite small project of our students. We think that git is the future in term of source control and git is much more powerful than SVN so, why have less when you can have more?
I publish this practical because it may be useful to others. Note that this practical is not a tutorial and it does not aim at being a git manual either. I think that their is plenty of very good documentation on the net starting by the famous ProGit by Scott Chacon. This practical is more about how do you work with git in a real life? It should be followed by a pair of student but you can do it alone if you manage split your brain in two.
It starts by forking an existing dummy C++ project on my personal github. After that, the two students are supposed to make some modifications (adding dummy classes, commenting code etc.) and share the work on their github using the most common git commands (add, commit, merge, fetch, push, pull). We examine at the end some more advanced features: blame, interactive rebasing etc.
Contrary to many practical that you may find on the web, this practical encourage the students to use GitExtensions. However, some tasks should be executed through the command line. I decided to promote GitExtensions because our students, for their great majority, are not computer geeks. They are not really friendly to the command line especially on windows (ENSAE computers have Win7 OS), so giving them a “command line only” tool would probably not convince the majority. Secondly, GitExtensions is really the best GUI over git that I have found, so why not use it? I use it at work and I switch from command line to GitExtensions depending on the task. Finally, GitExtension is “verbose” by default, this means that it tells what command line is being executing underneath, so it helps you learning git internals.
To conclude, that some will find in this document a complementary to git documentation such as ProGit.