jen moran

May 24, 2016

Version Control, Git, and GitHub – Explained

Tags: Git, GitHub, Version control

I didn’t know I was missing something in my “web design” life, until last semester when I was introduced to version control. Fast forward to this semester in Web Interactivity and having one of the first lessons reiterate version control, just instilled in me just how important this concept is. Thankfully, with this new addition to my coding life, long gone are the days where I had to save my files with alternative names and in awkward different folders just to separate versions.

What is version control?

Did my simple example give you an idea of what version control is? If you’re still a little confused (like I was at first), version control is simply a system that records changes to a file or set of files over time so that you can recall specific versions later [1].

Why is version control helpful?

So basically, it’s awesome! Especially if you a graphic or web designer as we typically enjoy saving every version/template we design. A version control system allows the user to revert back, view changes that were not only made over time, but who made them and why they did. If you work in a team setting this is particularly helpful for your situation as you are able to view teammates changes and read about why they did certain updates without having to figure out comments in code or waiting for their email back (it’s your source of communication). If you’re a solo designer, it’s especially helpful if five years down the road you need to revisit a site change you made and are unable to remember why you added or removed a particular command. Five year down the road you is going to be very thankful that you used version control.

How do I do this version control thing?

Version control revolves around the method of tracking changes. How do you track changes you ask? That’s through the method of committing. Once you work on a set of changes that modified the file, you can commit those changes, which then become tracked. The commits also receive a unique reference code such as a series of number or hashes.

Wait, what’s Git?

One of the most popular distributed version control system, and the one I learned to love is Git. Git is software that can be installed locally on your computer, which handles ‘version control’ for you [2]. With Git, commits can be labeled with a short “headline” type status, which quickly lets the reader know what the change does as well as the ability to describe a more in-depth explanation of the updates you just made. The commands within Git are also wonderful, you are able to check the status to see what changes have or have not been committed, see what the difference is between your last change and this one so you know how to properly label, and you are able to scroll through and see your progression over time.

Another great reason for Git is it allows the coder the opportunity to branch and merge (and yes they mean exactly as they sound). Woke up from a dead sleep because you dreamt of this crazy direction to go with your site’s header? No problem, branching allows you the opportunity to make changes without having to sacrifice the original state of the document. Then once your finished with your update if you love those changes you can simply merge your branches and your main copy will be up to date with your branch changes.

I’ve heard of GitHub, is that the same as Git?

Nope, sorry wrong answer, do not pass go and do not collect $200. Think of GitHub as the third party in this example. Your team is working on an important site update but your teammates cannot begin their part until you design the basics. Once you commit and make your changes you can upload them to a GitHub repository. From the repository your teammates will be able to “pull” your updates and then can begin to work on their portions of the project. So in essence it is a “hub for Git repositories”. What’s great is not only for your teammates, but future you is once again able to see your changes made over time, the code that was changed, and details about why you changed it.

Still confused? Here is a nice blog post to continue the conversation https://jahya.net/blog/git-vs-github/

Anything else I should know?

Basically, commit early and commit as often as you can (or as coordinated as possible). You don’t want to work on your header and then make changes to your footer and then commit UNLESS the changes and additions were part of the same purpose. Otherwise your commits will be all over the place and future you or teammates will be wondering what those two had to do with each other. You should also commit often so that you have a great timeline of not only your thought process but of major changes that might have been made that could alter and/or affect anything in the future.