Teaching Git & GitHub to Teenagers: Branching and Merging
Part 2 of 3 on Version Control for Students
This is one of a three-part series on how I teach Git & GitHub to high school students when necessary.
- Git Commits
- Branching & Merging (You are here)
- Collaborating
Warnings Revisited
In the last post I led off with some caveats, so if you’re just jumping in here, I want to reiterate the relevant ones here, but I’ll be brief this time.
- You probably don’t need to teach this. There are likely lower-lift tools for branching (like Glitch’s “remix” or “invite others to edit” options) that free up more instructional time for core CS content.
- Let go of industry best practices. We’re going to use branches a little bit sub-optimally. Student projects are generally simpler than those of professional developers, so we aren’t going to use the tools in the same way.
- Keep your lesson focused. We’re just doing basic branching and merging here, and trust me that is powerful enough to meet student needs.
Alright. We’re ready to jump in.
Framing: Branches for Feature Upgrades
From the first lesson in this sequence, students already know that GitHub can be used to save and back up their work, as well as to identify specific checkpoints (or commits) which can be used to revert their work later. However, they probably haven’t realized how this also empowers them to have multiple versions of a single project up and running in parallel. They’re likely thinking of it as a single timeline.
I usually lead off this second lesson by telling stories about using the web in the late 90s and early 2000s, when my personal favorite site, Neopets, would be taken down for a few hours about once a month for construction — sometimes the improvements were pretty invisible, but other times they would add entire new sections to the “Neopia World Map”. It was usually done between 2–6am.
- Why do you think they took the site down? Why do you think they did it at 2am?
- How long do modern websites go down when they’re being updated, like, for example, when Apple releases a new iPhone and needs their site to reflect that new offering? (not long unless something’s gone wrong)
- How do you think that’s possible?
Students usually come up with something similar to the idea of branches all on their own. It generally comes out with wording like “They’ve got a separate version already ready to go, and the just change the version” or “They keep a copy just on their office computers and don’t make up public until the last minute.”
It really doesn’t matter how students describe it, because as long as the come up with the idea of working with two versions of the same thing simultaneously, they’ve understood at least one purpose of GitHub Branches
Note: I promise, no shade to the early 2000s Neopets webmaster — I’m certain you all were also using some form of version control, but this example usually helps my students grasp the “why” behind branches in a way that makes sense for them.
Also, can I have your autograph? You’re why I learned HTML.
Branches, Unplugged
I’m not generally a huge fan of a lot of unplugged activities I see — I’ll defend that hot take in another post some other time. This one, however, I love.
I start by explaining that we’re going to try working together to draw a picture — the picture is half-finished, and I say “I’m not going to tell anyone what we’re drawing, but you can probably tell what it’s supposed to be based on the part of it that’s done already.”
Then I pass out copies of this drawing:
I explain that we will have a really limited amount of time (usually 1–2 minutes), which is absolutely not enough time to finish the drawing. I reassure everyone that that’s okay — the idea is that with everyone working together, we can merge together the best parts of all of our drawings. The thing we come up with together is probably going to be better than anything that we could come up with on our own.
Students all draw for that super-limited sprint, and then I collect the handouts.
The Problem: Merge Conflicts
I show off several of the drawings that students have done, and compliment one feature from each one — this isn’t meant to be an art class, and this is a metaphor, so positivity is the priority. Once we’ve gone through them all, I hold up any two that are recognizably drawings of a house and a tree.
We ooh and ahh over these drawings, and then I ask the fundamental question:
If we wanted to ask a computer program to merge these two drawings by combining the best features of these two different projects, what problem would we have?
Students answer:
- “There’s no way the computer can automatically know which features we want to keep from each drawing.”
I share with students that this is called a “merge conflict” and reinforce that it isn’t the end of the world. We can still merge these two drawings, we’ll just have to go line by line and specify which of the red lines to keep, and which of the green lines to keep.
The Solution: Feature-specific Branches
Then comes the reveal — before we started drawing, I secretly asked a few students in a whisper to focus exclusively on the left and right sides of the drawing.
Here’s what those might look like:
I show these two drawings to the class, and ask why this method of distributed collaboration is better.
Students quickly point out that these two drawings CAN be automatically merged — none of the features of either drawing is in conflict with features of the other.
As a bonus, students sometimes notice that these artists were able to add more detail to each of their drawings , because they were able to focus on just that one part of the project in the time we had — the teamwork & trust metaphors abound here, so feel free to tease that out as much as your students need.
The Conclusion: Separate Concerns Across Branches
Depending on the course, I’ll try to draw specific comparisons to files that they might already have in their projects, and which make for logical branches. For example, in a front end course where they’ve split the visual design and the functionality of a client-side script, I might say
- The HOUSE is your
index.htmland yourstyle.css— whoever’s working on this branch needs to make sure they never touch any other files, and once you know which elements your JavaScript partner is operating on, you need to promise them that you aren’t going to change the ids of those elements. - The TREE is your
script.js— whoever’s working on this branch needs to wait until the core HTML is in place before starting work, and you need to NEVER touch theindex.htmlfile, that way you can test your work.
This isn’t necessarily the best example, but it is probably the simplest.
A more authentic (but less useful) example might be to have Shea work on a branch called “Shea” where she’s creating shea.html, and to have Raul work on a branch called “Raul” where he’s creating a raul.html file, but that approach can get in the way of creating a coherent visual aesthetic without the two students needlessly duplicating one another’s CSS classes.
Bonus: When to Fork
Every once in a while, you’ll have a student who goes completely rogue on this sort of thing.
They’ll draw a bonkers illustration where the house becomes a vending machine and the tree becomes an octopus making a purchase from the vending machine.
I don’t usually spend a lot of time here, but I’ll often point out that when you’re diverging from the original project (instead of contributing to it) a Fork is probably a more reasonable way to handle that.
What’s Next
In the next blog post, we’ll talk about how to use this working knowledge of branches to facilitate work. This unplugged activity really isn’t that time consuming (about 5–10 minutes total), and I think the lesson is stickier / more memorable when you practice the concept right away. That’s why I usually do this post and the next one as one hour-long lesson. They’re only broken up here to give you, dear reader, a moment to catch your breath.
