Technical Blog 1: Understanding Git & GitHub


Hello again! I thought I wouldn’t get a chance to write to you for at least another week, but here I am on day 2, challenge 10, already creating my first technical blog! As you can probably tell from the title, today we’ll be talking about Git. Please refrain from making any references to Larry the Cable Guy. Deal? Okay, let’s get started!

So, What is Git?
The best way to picture Git is as your personal ‘Save’ button for everything you do in a particular file or group of files on your computer. When you create a document in Microsoft Word and then save it, you’re using something similar to Git! You’re saying to the computer “I like this file just the way it is right now. Please remember it.” Your computer will listen to you and keep that file exactly as it is until you delete it or save over it. And that’s where the trouble begins. You see, programs like Word and Photoshop and even most video games only let you save one version of a file. If you make a change to a saved file and then save again, that first save file is gone, and there’s no way to get it back. That’s what makes Git so fantastic. It doesn’t just save one version of your file, it saves all versions. Every time you go through the trouble of saving a file or group of files with Git, it remembers that version and the version you saved before it, and the version before that, and the version before that, all the way back to the birth of the file(s). The important thing to remember is to actually save, which is to say, commit your files to Git’s memory, early and often. The way to do that is through your Terminal. I know that might sound kind of scary, but trust me, once you save one file in Git, you’ll know how to save just about all of them. If you’d like to learn more about how to commit, check out this great guide for getting started. See, isn’t Git great? I haven’t even started talking about the option to include multiple contributors! We’ll get to that soon.

V1.0.3.5.9.3….
This method of saving every single version of your work is called version control. It’s important for the obvious reasons of never losing a single moment of your hard work. Check out this frightening example of how not using Git could be disastrous:

You’re working on a spreadsheet for the boys in Accounting. You’re making changes to Bob’s expenses from his business trip last week. You go to input $27 for his dinner but your hand inadvertently brushes the delete key and you wipe out an entire row. Even worse, you dont realize it’s gone until after you’ve already saved it. What row was that? Oh God, that was an important row! How do I get that back? Can I revert to a previous version? Why, oh why didn’t I use Git?

A lesson for the rest of us.

GitHub == A Home for Your Gits
So you’ve got Git. It’s on your computer, you’re using it, and everything is going great. But wait. What if you’re not at your computer? Or worse, what if your computer is lost or broken? Those gits, they automatically fly over to every computer you ever touch, right? And while I’m dreaming, can I have a cookie and a unicorn?

Saving files remotely (which means off your computer) is an extremely important process as a programmer, or as anyone who doesn’t want to lose their information. And that’s where GitHub comes in. GitHub is, as the name suggests, a ‘hub’ for your ‘gits,’ a website for storing and keeping track of all the work you do locally (which means on your computer). Any time you want, you can push a copy of your saved files through Git to GitHub and it will remain there with all of your versions intact. Now, GitHub isn’t the only game in town. BitBucket is another popular spot for developers and savers of all kinds to use for version control. Each website has its own benefits, but the process is just about the same for saving files from your computer to your site of choice.

I mentioned earlier that Git has an option to allow multiple players. This is huge in the development community, because it means that no matter how far-flung someone is, They can contribute to a program or process! This also means that once I get a job in programming, I’ll have a great excuse to work from home! Yay! (Just kidding, future hiring managers). The way it works is, you have your git hosting site of choice (GitHub) and on it, you’ve got a file or group of files, called a repository. These files are accessible by whomever you choose. For the most part, they’ll be public files that anyone can download and mess around with, but you can choose who gets to save, or commit new files to your repository. If you’ve got a guy in Tokyo and a gal in Texas and you’re in Florida, you can each be working on different pieces of code at the same time without accidentally deleting files or stepping on each other’s digital toes. Once the individual users are ready to submit their work, everything can be merged together (carefully) and the pieces complete the puzzle! Sites like GitHub allow for this awesome collaboration.

Well, that’s it for me from the technical side. Look out for my next blog, coming to you as early as tonight and as late as tomorrow morning!

My name is Edwin Unger, and I’m a web developer. Sort of.