I, like many young programmers, had an immensely difficult time learning git, and after mastering git myself and years of teaching git to coworkers, (That's right! You can get your PhD without knowing anything about git...or computers, but please don't be that guy. Us lowly Bachelor's degree boys will thank you.) I've noticed a couple trends.

My Experience

I first used git to solve a common classroom problem: collaboration. I was a freshman mechanical engineering student in my first computer science 101 class. The entire semester went without any major bumps (from this class anyway), and then it happened. We were assigned a group final project, and to make matters worse, there were only 2 groups, so half of the class was Team 1, and we were Team l (that's Team lowercase L) because we were an audacious bunch.

Up until this point we had been programming solo, so there was an obvious question: How do we share and divide our work? Should we all do a separate piece and then copy-paste them together later? How about we all develop on Google Docs? What could go wrong? Our professor of course suggested git. We asked a bunch of questions which were essentially answered with GitHub and Sourcetree. What we heard was essentially "We use Sourcetree to put code in GitHub where we all work collaboratively; just like Google Docs!" Any of this sounding familiar?

Here's the problem with all of this. We all made a GitHub account, and then never really understood git. What's a remote? How do I write my copy of the code to "git?" If you already have some git experience, I'm sure you've also guessed that literally every single push was a huge merge conflict which we then followed up with a good ol' push -f. Anyway, we wound up copy-pasting code into a Google Doc, and avoiding git as long as feasibly possible.

The big controversy

Stop telling students about GitHub! (and Gitlab! and BitBucket! etc.) At least hold off on telling them for a little while. Lot's of people—yes, even seasoned engineers in Fortune 500 companies—don't realize that git functions completely independent of GitHub. As a result, they often don't understand the true purpose of git, and therefore don't understand what a good git workflow looks like.

What is git?

At it's core, git is a version control system, which means you use it to store multiple versions of the same thing.

The simplest use case is where you're working on a project alone, and every time you make a bit of meaningful progress, you save a copy so you can revert back later if things get crazy down the line. (If you don't know what I mean by "meaningful," I've got your back.) The absolute simplest way to do this (albeit, the messiest, so please for the love of Linus Torvalds, don't do this) would be to make a new folder and save copies of every snapshot. Git can do this for you though and save you a huge headache and an embarrassing desktop full of MyProject_Latest/, MyProject_LatestER/, and MyProject_LatestFINAL/ folders. You know who you are. Basically, instead of making a new folder, you make a new git commit and you have yourself a version.

With the most basic workflow, this is all git does for you. Git just tracks versions of things.

What is GitHub?

Now, GitHub is a separate animal. GitHub, at it's core, is just a place to store git repositories. You get a cool GUI to see branches, commit diffs, etc., but mainly it's storage. Because it's remote storage (which you can have without GitHub), it brings out the collaborative part of git. Essentially, you can have multiple developers adding their versions of the project to this central repo.

This of course presents all kinds of issues that aren't accounted for in our simplest case workflow above, but that's a conversation that needs it's own post.

TLDR;

  • Git is a version control system. It saves versions of your code.

  • GitHub is remote storage.

  • Start your (or your students') git journey without GitHub to save everyone some confusion.