How to Teach Git Commits & GitHub to Teenagers

Part 1 of 3 on Version Control for Students

Photo by Jeremy Bishop on Unsplash

This is one of a three-part series on how I teach Git & GitHub to high school students when necessary.

1. Git Commits (You are here)
2. Branching & Merging
3. Collaborating

Should I Teach Git?

Teaching Git to high schoolers or early college students is a really delicate process, and any tips shared here come from having done it wrong many, many times. I don’t claim to be an expert, just a very seasoned failure who has channeled those mistakes into a lesson plan that works. Before I get too deep into this, let me offer a few caveats:

1. You probably don’t need to teach this. There are so many incredible tools out there that foster collaboration in a much more seamless, familiar way. Glitch, Repl.it, AWS Cloud9, and many other education-focused tools all have built-in collaboration features that work a lot like Google Drive: you invite your team members in, and then everyone can live edit the code together. You can watch them make changes on your screen just like you can in a Google Doc, which is the word processor most students are accustomed to using. Most of these platforms have some form of “document history” built in too, meaning there’s some rudimentary version control included as well. Git feels, at first, like a more complicated variation of other tools, and learning something before it feels useful is almost always a net negative experience.
2. Let go of industry best practices. At some point over the next few paragraphs, I’m going to recommend at least one method of using Git that your roommate who is a senior developer will scoff at. Some of the ideas I’m offering have a lot more to do with how to manage student collaboration, and since students are usually building simpler projects than professional developers, it doesn’t always make sense to use the tools in the same way. With that said, if I’ve advocated for something with which you disagree vehemently, feel free to head on over to my Twitter and say hello world. I’m always eager to learn, grow, and revise my writing and teaching practices based on input from others.
3. Keep your lesson focused. Look, Git is incredibly robust. There’s just no way to teach everything Git can do to students and get them to a place of mastery in one lesson — even most developers master only the pieces of it that they need for their specific workflows, so narrow student focus to the 1 or 2 workflows they need, and throw in the disclaimer that Git can do a lot more that we won’t cover today. I generally teach Git in three separate lessons, each with a microscopically narrow focus: Committing, Branching & Merging, and Collaborating.
4. Try other tools based on your teaching context. I’ll share the lessons I’ve created here, but GitHub Desktop and the Git capabilities built into Atom and other editors are really powerful. It may be that you get more mileage with students using some of those technologies. My interest in teaching Git from the command line is rooted in the fact that I often teach students who only have access to Chromebooks, so downloaded software often isn’t an option, but command line in web-based IDEs almost always is.

Okay, now that I’ve got some of those framing pieces out of the way, we’re ready to get started.

Prerequisite: Use Git To Share Code

At Upperline Code, we keep almost all of our labs (code challenges) and lessons on GitHub, which means that for the first eight hours of class, students are continually asked to type git clone some_repo_url_here in their terminals, and then they watch big folders full of code snippets appear almost instantly on their hard drive or remote workspace. The word “clone” is generally familiar enough that you don’t need to explain this with too much detail for students to grasp what’s happening.

The first activity students clone down in our courses is actually a lab designed for the sole purpose of familiarizing students with the cd, ls,pwd, and open commands, and I think that some fluency in at least those four core commands is really helpful to making later Git commands feel more familiar.

Commits as Checkpoints & GitHub Pages

My first lesson on Git usually comes on day 2 of an immersive course, so students have already used git clone several times. Most of our code challenges start as Git repositories, and students generally know that one of our teachers wrote those repositories because they’ll notice our pictures among the collaborators. On day 1, I also make an effort to use the words “Git”, “GitHub”, and “repository” as frequently and precisely as possible, so that they’ve had some time to get familiar with hearing those words in context, even if they aren’t 100% sure what they mean.

Vocabulary

At this point in the course, I can usually ask: “Based on your experience yesterday, how would you describe the website GitHub? What is it?” and students will generally come up with something like this:

GitHub is a place where you can save your code and share it with other people.

Which, for our purposes in this lesson, is a great working definition. I usually also take a quick second to offer some core vocab to students in student-friendly language as well:

• GitHub is a website where you can store and share your code; it can serve as a backup if your computer ever crashes, as well as a sort of portfolio you can share with future employers who want to see a sample of your work.
• Git is the command line technology that allows us to send code to GitHub and to get code from GitHub. It can also work with other websites, but GitHub is the most common.
• A Repository or Repo is one project, generally made up of multiple files. Typically when you clone something down from Git, you’re cloning a repository, which is why you get a whole folder full of files, not just one single file.

Framing: Git is the OPPOSITE of Google Docs

With critical vocab out of the way, I usually start by asking students how you save your work on Google Docs. Students are quick to correct me — “You don’t save anything; it happens automatically.” I follow up by asking if anyone has ever worked on something without an auto-save feature, and honestly not a lot of them have, but that’s okay, because they’re usually still able to imagine the horror of working for three hours on a project and suddenly losing all that progress.

Git could not be more different from the word processing software students are used to using. Not only does Git not autosave, but it breaks saving down into a laborious three-step process:

1. You have to specify which files you want to include in this save (or commit).
2. You have to name your save (your commit) with a commit message, thus finalizing your choices of which files to save.
3. You have to back up this save (this commit) by sending it to GitHub.

Benefits of Laborious Saving

Before actually executing this process, I often ask students why they think this much more laborious process of saving work is actually better for a developer — As a teacher, you should almost always talk about the why before demonstrating how, especially when the skill seems as tedious as this one. Here are the reasons students posit most often:

• You never accidentally save a file you didn’t mean to with half-finished changes. Saving at automatic intervals would create some pretty cluttered edit histories, and it would be tough to find saves with working code.
• You have to name the commit, so if you need to come back to this specific moment in time, it’ll be easier than browsing the Google Docs history for timestamps.
• Pushing your code up to GitHub means it’s always in at least two places, so even if your local machine breaks, you’ll have another copy elsewhere.

Now that we have a rationale for this three-step process, it’s time to show students how it works.

by Randall Munroe, from xkcd

The add-commit-push Git Workflow

Our conceptual understanding is in place, so it’s time put this into practice.

I have students start by forking a repo that I’ve made ahead of time with 2–3 files in whatever language they used on day one. The point here isn’t the specific project at all, but for the sake of a clear example, we’ll imagine a course that includes some HTML — most CS teachers know it, and as a bonus, it plays nicely with GitHub Pages to put a cool bow on this lesson.

I share out the link to the repo, show students where the fork button is, and then point out that they’ll know they’ve got their own copy of the repo when the username up front no longer shows my name, but instead shows theirs. I usually have them lean over and do a partner check here as well, just to make sure. Really emphasize this visual cue, because if students are cloning from YOUR repository, they’ll be unable to push back up to it later, and this is the only moment when preempting that mistake is easy.

Next, we git clone the repo down as usual, and then cd into the directory.

I ask students to make a change to the index.html file — something really simple like “Add an h1 with your name inside it.”

I follow up with some additional steps: “Be sure to SAVE the file after you do that. Now that we have changes that need to be sent to GitHub, let’s get ready do do those three steps we talked about earlier.”

Step One: Add

Specify which files to commit. First, we run git status, and I ask students what they notice. Most terminals color code the files with untracked changes in red, so this aligns with student understanding really well.

We run git add index.html and I highlight that Git gives you absolutely no indication that the git add command has worked at all. So we follow up with another git status and talk about how the green color coding means that step one was a success.

Step Two: Commit

Seal these changes up in a commit with a specific name. Coach students to write git commit -m "Adds Jeff Header" and encourage them to adapt this commit message to say what they added, which likely only means subbing in their name for yours. Mention that it’s SUPER important to close the quotation marks, but consider demoing what goes wrong for everyone; depending on how many keystrokes a student has typed, you can usually solve this by simply closing the string and hitting return. That may feel trivial to you, but it sends students into a panic to see your screen doing something totally different from theirs.

On that note, if you have a class of more than 4 students, at least one will end up opening VIM at some point during this lesson — usually because they’ve somehow managed to create a merge conflict.

I’ll admit that some level of VIM literacy is an important part of the Git ecosystem, but Fluency in VIM is not actually necessary to get a project off the ground. More importantly, VIM feels to most high school students like “this weird hell-hole that you get sent to if you make even one mistake” (actual student quote), so I’m often looking to minimize the time students spend with it. Glossing over VIM frees up mental bandwidth for students to focus instead on Git, the central objective of this lesson.

If a student manages to put themselves in the situation, demo and normalize the error, explain in 10 words or fewer what VIM is, and then have the student who got stuck type :wq to commit the merge and exit VIM. Be sure to emphasize that this isn’t actually an error, just the computer’s way of letting you finish what you were working on, and then have everyone type git status again to confirm we all made it safely through the woods.

Note 1: Students may be prompted to configure their git settings with a username and email. It’s easy to do following the instructions that are printed in Terminal, but the instructions are intimidating, so be sure to demo this for students as well.

Note 2: If you feel deeply convicted that VIM fluency is a “must-have-right-now” skill, my favorite tool to demystify it is openvim.com.

Step Three: Push

Send this commit to GitHub. If students cloned their content down from a forked repository, this process will be easy: have them git push, then follow the prompts for them to type their GitHub username, and then their password, which as of fall 2021 must now be a token. Let students know that the password/token isn’t going to give ANY visual feedback, but it is working. Just type precisely and carefully, tap return, and celebrate your first fully finished commit!

During step three, there are some common errors that will keep students from pushing their commit up to GitHub:

1. Students are pushing to YOUR repo instead of their own. Type git remote show origin and confirm that it’s mirroring their repo instead of yours.
2. Students haven’t created a GitHub token, and are typing their password instead.
3. Students hand-typing their token, which is a HUGE string of characters, and impossible to do without making mistakes. Encourage them to copy-paste and be sure not to include extra whitespace.
4. Students created a token, but forgot to scope it with repo permissions.

Once you’ve waded through all the errors, and the push is successful, have students refresh the repository on GitHub, and point out that these changes have been pushed through. The index.html should show that it was modified recently, and if you open the file on GitHub, you should see your changes.

Deploying to GitHub Pages

This last piece is the reason I prefer to do this experiment in HTML. Model it for students, and then cut them loose to do the same thing.

1. Click on “Settings”.
2. Scroll all the way down to the “GitHub Pages” section of the Settings. If you hit the Danger Zone, you’ve gone too far.
3. Have them select the “Main” branch for the source.
4. Wait about 2 minutes. Then click the link.

Students absolutely LOVE this. GitHub Pages isn’t meant to be a hosting service, and we never pitched it to students as such, but seeing your project up and running in this form where you can text it to friends is really exciting.

As a bonus, deploying to GH pages means that future pushes to the master branch will be reflected on those sites, so if you use this lesson as a launching point for an HTML & CSS project, students get a lot of practice with the add-commit-push workflow because they’re excited to see each new set of changes go up to the version they’ve texted out to their friends.

Other Tips

There are honestly 100 other tips and tricks I might use, and each one kind of depends on where students’ sticking points are.

For example, I had one cohort where my students were using “second commit” or “third commit” for each new change they made, since they had seen me lead off with “initial commit” as my demo. This is obviously suboptimal, but students hadn’t realized where commit messages show up on GitHub, so they hadn’t been given a reason to come up with more descriptive names, so in that situation, we took a minute to examine the commit history of another project I had been working on so that students could see why giving commits more specific messages could be helpful later on.

That’s just one example, but I share it specifically to point out that this article is not THE way to teach Git and GitHub. It’s actually neither fully optimized nor completely comprehensive. It’s just the way with which I’ve had the most success getting the greatest number of students to a place of confidence with a tool that used to terrify them.

Here are some other small levers I sometimes use, but please feel free to drop your own tips and tricks into the comments:

• Right after students clone the project, I might have them git remote show origin next, so that they notice the same URL that they cloned the lab down from — we don’t need to do anything here, we’re just taking time to familiarize ourself with some of the more behind-the-scenes features of Git.
• After the lesson ends, I almost always throw an anchor chart up on the wall with status, add, commit, and push examples. I usually leave that poster up for the duration of the course.
• I try to point out that students can make changes directly on GitHub via the browser interface, but I also plead with them never to do this until we’ve had more practice. It’s the most likely way for students to get a merge conflict if they’re working on a project directly on the main branch without collaborators. That’s a topic I don’t really want to address on our first day using Git.

Up Next: Branching & Merging

Thanks for taking the time to think about this with me. Bear in mind that the process I’ve described here is really ONLY designed for version control / saving student work. The next post discusses Branching and Merging, which is honestly the piece of this sequence that has helped me the most.