Welcome!

If you spend any significant amount of time around software developers, you will sooner or later hear one of them talk about something called GitHub. Despite being a software developer myself, I have somehow managed to get all the way to my senior year of college without ever using GitHub. However, it has been brought to my attention that I will almost certainly need to use GitHub or a similar tool once I graduate from college and enter the workforce. Since I highly doubt that I’m the last person who will ever feel a bit intimidated by getting started with using GitHub, I have decided to document my experience in the hope that it will prove useful to those who come after me and find themselves in the same situation. Over the course of the next several weeks, I will be providing you with a guided tour of my GitHub exploits that I hope will cover all of the basic tasks a new GitHub user will need to perform to use the platform effectively. For now, we’ll start with a brief explanation of what GitHub is.

What is GitHub?

According to Wikipedia, GitHub provides Internet hosting for software source code and distributed version control. The first part of that sentence is relatively simple to understand: it lets you store code on the Internet so you can access it (and modify it) from anywhere. Version control, essentially, means a system for tracking changes that are made to the code. On GitHub, the code for any given piece of software lives in a repository, or repo for short. Each time you edit a file, you commit (save) the changes to the repo. GitHub maintains a commit history for each repo so that everyone with access to the repo can see when and by whom each change to the code was made. This way, if another member of your project team sees a piece of code they don’t understand, they can look at the commit history to see who wrote it and ask that person to explain how the code works. (Maintaining a commit history also allows you to undo a change if the need arises, but that can get…icky, especially if the change was made a while ago.)

What makes GitHub a distributed version control system is that everyone working on the project has a complete copy of the repo (called a clone) on their local machine. The copy stored on GitHub.com is the reference copy (i.e. the one that will be used to run the application in production), but no developer’s local copy is fundamentally any better or worse than any other developer’s local copy or than the reference copy. This contrasts with a centralized version control system, where there is only one complete copy of the codebase and developers only keep local versions of the files they are actively working on. Using GitHub, developers can make changes to the code in their local copy and then push those changes to the reference copy so the whole team can see them. To limit the potential confusion that could be created by multiple conflicting edits to the same file by different developers, each developer will create a branch on the repo so that multiple altered versions of the same file can be kept separate when the changes are pushed to the reference copy. Once the changes made on a branch are reviewed by other developers and any potential conflicts resolved, the branch can then be merged into the main codebase. Developers can then update their local copy of the repo to reflect their codevelopers’ changes by pulling those changes from the reference copy.

So there you have a basic summary of what GitHub is and the high-level overview of how it’s used. Next week, we’ll begin our adventure by creating a GitHub account and installing the desktop client.