One summer, when I was a kid, I worked at Chuck E Cheese. On the job, they would rotate you to different roles every so often: front door greeter, pizza maker, video game manager, and even being Chuck E Cheese. (They did this so you wouldn't get bored, I guess, because you could mindless do any of these.) Being Chuck E Cheese was the worst. I had to wear this heavy furry costume with a big fake mouse head. It was hot inside and you couldn't see all that well out of the eye holes. Little screaming kids hyped up on soda or because it was their birthday ran around you and tugged at you. Worse, you couldn't say a single thing while you were in costume. Chuck E doesn't talk, you see, and you had to stay in character. But the worst part was the smell. That's because after each use, the costume didn't get put in the washer or anything. It was just sprayed down with Lysol and hung up for the next poor sap whose turn it was to be Chuck E Cheese. The first minimum wage job you chose as a kid: that's one I wish I had back.
If I could go back to that summer, I would maybe show a little more ambition, you know? Like spending the summer writing, learning to become the next great American novelist, or Ruby inventor. But there's no takebacks in life, really. If life had version control, there might not be such a thing as regret! No this is not guerilla marketing for Hot Tub Time Machine 2. It's my ham-handed attempt at illustrating version control. Because if life had Git, a version control software, I could rollback to that fateful summer, spend those careless days chipping away on an old typewriter or Commodore 64, instead of having filled out that ill-fated worksheet that was my Chuck E. Cheese application. With Git and other version control software, one can take "snapshots" and revisit them if the current version doesn't work out. Not with life, of course, but with digital files of photos or essays or, more commonly, source code. Which is nice, because code is very ethereal-- it can be easily lost. Besides the time-travel aspect, Git manages collaboration. In the real world, especially in the workplace, teams of people work together, often simultaneously, often around common files. Git directs traffic, so to speak, so that one person's contribution doesn't clobber someone else's. Git does nothing to solve labeled sack lunches from being stolen and eaten by co-workers though.
GitHub is a website that can host Git repositories. (A "repository" is just the metaphorical basket holding the stuff of what you want to keep versions.) Because it's on the internet, your digital stuff and its versions can be powerfully accessible, particularly for collaborators. To better conceptually understand the relationship between Git and GitHub, it's important to understand local vs. remote repositories. When you develop stuff and track its changes, you are using Git locally, because the repository of those files is located on your computer or a "nearby" network computer. To share your work, your collaborators could crowd around your desk and look over your shoulders. ("Craig, did you have a tuna melt for lunch by any chance?") Oooooor you could "push" the repository files to a centralized, highly accessible remote location, like GitHub, where everyone can "pull" down their own copy to view from the comfort of their own personal space! GitHub, in essence, is like the mothership for repositories.
And that's it. Hopefully from this post, you've picked up a little something about version control, Git, GitHub, and life's regrets.