Teaching Git & GitHub to Teenagers: Collaborating
Part 3 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
- Collaborating (you are here)
Collaborate With Git
If you did part 1 with students, they should feel comfortable with Git commits as a way of saving work at different stages of development.
After that, if you did lesson 2, students started to build a working understanding of WHY they might want to create Git branches. This lesson focuses on the HOW.
In the previous lessons I offered some caveats. Please consider going back and reading them, but there are two that feel worth reiterating in context here:
- 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 collaborating on a single repo — we’re not going to worry about forking and setting up multiple remotes.
Now that that’s out of the way, let’s get into some guided practice!
Step 0: Designate an “Owner” and a “Collaborator”
Break students into pairs, and designate one person to each of these roles. It really doesn’t matter who is who, but these titles will help you give clear instructions as to who should be doing what on which machine.
If you have an odd number of students, have one be your collaborator.
Step 1: Create a Repo
Only the OWNER should do this.
I generally like to let students create their own repo, clone it down, create one file, and commit and push that one file to master before branching. For now, the Collaborator is operating as a pair programmer, helping with the add-commit-push workflow that isn’t new, but is probably not yet fluent.
Step 2: Add the Collaborator
Have the owner do this in GitHub Settings, and have the collaborator check their email to find the invitation. It is not at all surprising for students to “not get” the invitation to collaborate on a repo. This is generally because they’re checking the wrong email, or because the invite was sent to the wrong GitHub user. Double check both parts.
Students generally struggle with this step a fair bit because everyone somehow manages to set up their GH notifications differently — some folks get the collaboration in their email, others see it in their GH account under the bell icon, and still others won’t get it until they navigate to the repo itself. Just make sure to show them on your screen the difference between a pending invitation and one that has been accepted, and then ask the “owner” of each repository if their collaborator has accepted yet.
Plan to spend more time than you would expect on this step. It always surprises me how much longer this takes than I plan for.
Once that’s done, have the collaborator clone down the repo.
Step 3: Both Partners Make a Branch
Generally, the part of this I’m most keen to avoid is the confusion that can arise when you create multiple new branches — it takes a while to realize that new branches are copies of whatever branch you were on when you created them. Add to that the fact that uncommitted changes follow you from branch to branch and committed changes don’t, and you’ve got a LOT of room for students to intend one thing and accidentally do another.
To keep it simple, I usually ask students to use branches to represent PEOPLE, not features, so I have each student create a new branch and name it for themselves.
git checkout -b "teddie"I usually also as them to git branch right after so that they can see both their branch and the master branch, and start to understand how that interface works.
Step 4: Add Changes!
The point here isn’t to actually MAKE something, but rather to just prove that it can work, so I usually just encourage each student to do one task. It’s important to be clear about which student is touching / making which file.
OWNER: Create an index.html file at the top level of the repository and populate it with the standard HTML shell. Then add one anchor link <a href="your_partner_name.html">Click to see my partner's page</a> which links out to your partner’s page — it won’t work on your branch, and that’s okay.
COLLABORATOR: Create a yourname.html file at the top level of the repository. Populate it with the standard HTML shell. Then add at least one paragraph element with a sentence about yourself.
Step 5: Add-Commit-Push!
If you’ve already done the lesson from my last post, this part is easy. If you’re trying to spiral it all into one lesson… please don’t? Or if you do, good luck?
Students will git add . , then they will git commit -m "some memo" and then git push and it’s only in this last step that anything will go awry.
The console will tell them there’s no branch to push to, but it offers the solution with no changes necessary. For example, if Marisol is working on a branch that is named “marisol”, then the console will prompt the student to git push --set-upstream origin marisol and once that’s done, she’ll see the success notification as usual!
Note: we use the rather reckless
git add .to manage this workflow for now because with a simple front-end project, this isn’t going to cause us problems, but depending on what you’re teaching, you may need to introduce either a .gitignore file or require the more manualgit add filenameto keep files like a package-lock.json from causing merge conflicts before moving on to more robust projects.
If you’re running short on time, or if you teach in shorter blocks, the end of this step is really good stopping place. You can go over merging the next class day.
Step 6: Merge on GitHub
Next we take some time to show where branches are displayed on GitHub — this drop-down menu is so inconspicuous, but showing students that their various versions of this project are available is generally pretty exciting.
Show students how to create a pull request, and normalize that they should never merge their own work to master — they need their partner to approve those changes.
Have each student create a PR, and then have each one merge in their partner’s PR. If they followed instructions correctly, there will be no issues. If they somehow managed to create a merge conflict, then ask for permission to borrow their computer or share their screen and GET THAT MERGE CONFLICT UP ON THE MAIN SCREEN! It’s really easy to resolve merge conflicts in GitHub’s browser interface, so use this as an opportunity to both reinforce why students should agree about who is touching which files ahead of time, and also to calm them down and show that if it DOES happen, it’s not actually a big deal.
Step 7: Sync Up with a Pull
Once both partners’ branches are merged in to master, point out that even though the changes are merged on GitHub, those changes don’t show up in students’ local repos. Students are generally quick to catch on to what’s happening here, so I don’t spend time digging in to the concept, I just tell them how to update their local repos.
Have both partners run a git pull origin master to get their local branches updated to match the current master branch. Since all merge conflicts (if any) have already been resolved on the cloud, this means that 99% of the time, local repos update without students ever seeing VIM (or whatever is set up as their default command line editor) at all.
Step 8: Rinse and Repeat Steps 4–7
This process of communicating with your partner to normalize co-ownership of a project is so important, so pushing in a few more changes with the time you have left is a great way to wind down this class.
Bonus Workflow Diagram
I usually draw something like this on the board to illustrate what happens, and I start with just “remote master” and add local and remote branches as we go. Here’s what it looks like when we’re done:
This diagram-making exercise helps about a third of my students, and the rest usually ignore it, so I wouldn’t rely on it too heavily, and I definitely wouldn’t drop it on them all at once.
What’s Next
With this introduction, we’ve set the stage for doing some more intense collaboration. In general, when I offer this workflow to students as an option, about a third of them take to it and really start to love it, and the other two thirds tend to gravitate more towards other forms of collaboration, like zipping projects and sending them back and forth, or copy-pasting entire scripts in Slack.
I truly think that offering them the freedom to use the tool only as much as they see the value in that tool is a really honest way of earning student trust. If no one takes you up on the offer to use Git and GitHub to collaborate, odds are you introduced it before projects were complex enough to make it a truly useful tool.
In other words, make space for students to use this workflow after you show it to them, but try to be open to the feedback that it may not be super helpful for them right now.
