If you’re currently a programming git, you’ll want to start understanding version control. Why, you ask? Because, unless you’re superhuman, you’re going to make some mistakes over the course of your project. Even if you are superhuman, you’ll probably want to look back and admire your handiwork at each step of your project. This brings us to the practicality of version control.
Version control is: how you manage changes to your project over the course of time.
One day, genius strikes. You are suddenly overcome with an idea for the perfect novel, and your new project begins. You begin writing Sleepless in San Francisco on Monday.
On Tuesday, you make an addition to your novel. Because this is now a modification to the original, we’ll call this Version 2.
Over the next few days, you continue making additions, and thus, new versions of your novel.
Let’s say that, on Friday, you decide that all the work you did since Wednesday was crap. Wouldn’t it be nice if you had an exact copy of your novel from Wednesday? Welcome to version control.
Version Control Systems, or VCS, allow you to access your project at different stages of development. Now, not every VCS is created equal.
If you were writing your novel on Microsoft Word, and consistently saving each version under Sleepless in San Francisco.docx, there would be no way to access the work you did on Wednesday. If you were saving each individual version, all you would have to do is access Sleepless in San Francisco3.docx.
This is the idea behind Git.
Git is a VCS that saves, or commits, versions of your project as separate, accessible files. These files are located on your computer in something called a repository. Think of a repository, or repo, as a folder for different versions of your project.
Mercurial is Git’s biggest competition. Mercurial has a slightly different command system; users tend to note that Git has a steeper learning curve. There are also aspects of Mercurial that make for better handling on Windows systems, though the release of Git’s msysgit has helped bridge that gap.
The biggest difference between the two systems is the handling of your project’s history. Let’s go back to Sleepless in San Francisco.
Time travel back to Wednesday. You’ve had 3 straight days of writing, and you’re sick of it. You ask your devoted best friend Becky to write Chapter 2 for you while you continue on with the rest of the book.
Becky works diligently until Friday, when she sends her chapter over to you for revision. Of course, you love it (it’s Becky). You then merge her version with your master version.
This is another powerful aspect of version control. A good VCS does not simply append time-stamped versions of your project. Separate parts of your project can be logged in separate branches, then integrated, or merged, with the main project.
Git and Mercurial think about these branches differently. For a long time, Mercurial functioned under the constraint that your project’s history was sacred. The points at which you commit your project could never be changed. Alternatively, Git has long employed the use of flexible branches, which can be moved around and renamed depending on the history and future of your project. Mercurial created some extensions (such as bookmarks, and rollback) that helped increase functionality, but ultimately, lost out to the efficiency and flexibility that Git provided it’s users.
Now that you know a little more about why we use Git, let’s talk about something called GitHub.
GitHub is an online platform that gives you the opportunity to show off your shiny new project. Think of it as a writer’s forum for Sleepless in San Francisco. Your novel can be read and edited by others, downloaded to fans’ computers, and even turned into a starting point for new novels.
When you create a new repository on GitHub, you give your project a place to live remotely (somewhere in the magical interwebs). You can work on it on your own computer by pulling the repo from GitHub to your local repo. To commit your changes to your GitHub account, you’ll have to commit and merge your local repo back to your remote repo.
Other GitHub users can view and modify your project, as well. They can also fork and clone your repo and make their own shiny new projects. These are some of the reasons GitHub is such a powerful tool for innovation: it gives programmers access to hundreds of projects and allows them to build and customize as they see fit.
There are, of course, competing remote VCS companies. GitLab seems to be a viable alternative for programmers looking to keep their projects private. Bitbucket, has the same general functionalities as GitHub and GitLab, but lacks a particularly clean and efficient user interface.
Something to keep in mind:
Recently, GitHub fell offline and programmers took their first ever “snow day.” This sent the world of remote VCS a-spinning, and Twitter a-Tweeting.
The magical cloud has its problems, too. Keeping an up-to-date local repo is generally a good idea, as you can continue to add and commit new versions without pushing your project remote. Remember, gits don’t let GitHub get their Git down.