What the Hell is Git?

This is information is regurgitated from the Pro Git book, written by Scott Chacon and Ben Straub at git-scm.com. I was directed to this resource via The Odin Project’s course on Full Stack web Development.

This article is written in the style of Open Source Notes. OSN are educational lesson summaries of a denser or longer publication. An OSN author reads the article or publication and writes notes on the topic in an accessible summary style. The purpose of this effort is to offer resources openly and freely that help others become acquainted with the topic, while the OSN author is learning about the topic. Links to the Master Publication and credit to its author are always included, so that if readers would like to explore the topic beyond the surface OSN level, they are welcome to do so. Cheers, and thank you for reading.

-Garrett Stephens

When I first began with web design, I heard the terms ‘Git’ and ‘GitHub’ all over the place. I went a very long time without ever understanding what those terms meant. In my mind, I lumped ‘Git’ into the category of engineer-ey terms that were just a step deeper than I need to search, along with terms like AJAX, vim, XML, SQL, etc. If you’ve used a website design CMS, or ‘Content Management System’, like Wordpress, SquareSpace or Wix, there’s not even much need for programming languages in your design process, as long as the website is fairly simple. However, as I dug in more to the programming and coding world, I saw Git everywhere. For me, my curiosity grew until I realized there was basically no avoiding the question anymore:

What the Hell is Git?

image from git-scm.com

Git is revolutionary not just as a program or a language, but also as a workflow. I’m confident that even those who will never type a single letter of code can benefit from understanding the way GitHub works and how techies use it for sharing, collaborating and optimizing overall process management.

image taken from a Google search for ‘Git’

Version Control

In understanding Git, first we have to understand what version control is. Chacon and Straub tell us that Version Control is “a system that records changes to a file or set of files over time so that you can recall specific versions later”. Why is this important? In programming, you edit a file many times while you make changes to your “program”. Keeping track of those edits in an accessible and open way is incredibly useful to programming efforts for a few reasons.

[1] Squashing Bugs
If you start out with a simple website, let’s say you have three files, titled ‘mywebsite.html’, ‘mywebsite.css’ and ‘mywebsite.js’. The file names and types aren’t important, but in web design, HTML is the file that tells a browser how to arrange the structure of a website. So let’s say that in this example workflow, you start with an extremely basic website, with a title and an image behind the title. You save the html file for the website.

image from vibewebsolutions.com

Then, you decide to add new parts to that page, like an introduction, a picture of yourself and a couple pictures of your project. The page starts to look more like an actual functional webpage (look to the left). However, you make a ton of changes and then save the file with the same name ‘mywebsite.html’. This simply overwrites the old file and is now the only “version” of mywebsite.html that you have.

If you continue to add chunks of “code” and save and overwrite old versions of your program, you will quickly lose track of the changes you’ve made to the original file. In the world of programming, one of the biggest problems that arises is troubleshooting. So let’s now say the home page of your website has a header, a menu, a title, several introduction paragraphs and a whole grid of pictures. Or whatever, it’s just a complicated design, is the point. If the website stops running and returns an error message, or there’s some weird error message, you need to isolate the problem and figure out what’s happening.

If you just have one file, you’ll have to dig through the entire file looking for errors. That sucks. This is what html looks like, for reference:

image from wisegeek.org

So now, you have to dig into that and figure out where in the whole “script” or program that you’ve made a mistake.

Alternatively, you are given a chance to reverse time and use Git. Now, every time you save the file as you’re working on it, Git stores a “version” of the file. You edit, then save. Edit, then save. Edit, then save. Edit, then save. You now still only have one mywebsite.html file, but you can access each of the versions you edited on Git’s “repository”. This allows you to troubleshoot much more effectively. You can think: where exactly was this mistake made? If Version 4 of mywebsite.html still runs fine, but Version 5 doesn’t, then the error was likely from changes you made between 4–5.

It is important to mention that this is not perfect troubleshooting. It could be that you made a mistake back in Version 2 that didn’t manifest until, say, you added images in Version 4. In this case, the error appeared in Version 4, but the source of the problem was really because of your poor code written back in Version 2. The point to takeaway is that git helps you break up a programming project into multiple versions, so that you can trace bugs more effectively, rather than just trying to crawl through long code files running the files and testing them until they’re fixed.

[2] Trying out new things (& A|B testing)
When you are doing something like building a website, there might be different things you want to try out in your design process. If your website is simple, maybe you want to try out an image slider below your text introduction. You think that would look cool, but you’re not sure. You can save (git calls this “commit”) a Version of the file where you’ve added a slider. Now maybe you think this looks kind of cool, but not as totally tubular as you’d have hoped. So you git commit that bad boy as Version 5a of mywebsite.html but “revert” back to Version 5, which doesn’t have the slider. Sometime in the future, if you have a great idea for where an image slider could fit in your website, you can refer to your Version 5a via Git, so you don’t have to rewrite all of the code you worked so hard on.

There is always a “Master Branch”. Think of the Master Branch as the final product. When you make changes, you grab a copy of the Master and your copy is known as a “fork”. You can make changes on the branch that you forked without affecting the Master at all. Then, when everything looks great, you can “merge” your branch into the Master. ‘Merging’ just means that from your fork, you are combining your code into the Master Branch, simply overwriting the old code that was there. By doing this you create a new Master.

A|B testing just refers to trying out different versions of projects in comparison to one another. So maybe you have 3 versions of mywebsite.html that seem equally rad, but you’d like to run them and track how your web site’s visitors respond to each version. You can have a master mywebsite.html that branches into these 3 separate formats, all as different branches, different versions. You can swap your code between the variances on the fly and test at your leisure.

[3] Teamwork Making the Dream Work

Git helps programmers collaborate, and helps managers keep an eye on the progress of a project.

Let’s say we’re all sitting at a meeting and Jonny and Sarah are totally going at each other’s throats, once again. Sarah thinks a home page with a nice video background, the name of the company and a small “explore” button will lead to more sales on our company’s tinfoil hat sales-based ecommerce website. Johnny thinks that’s bull and that a pop up window should appear right when someone visits the site, advertising to the site visitor that all hats are half off this month and that the next page after you close the popup should be filled with animated pictures of tinfoil hats vibrating with large “buy now!!!!” buttons below them.

Jonny’s obviously wrong, but being the data-driven company we are, we want to A|B test the two strategies to get consumer data on which strategy leads to more sales. Using git as version control, Jonny forks the current version of the website and starts working on his disaster of an idea. Sarah also forks from the same repository (from the Master) and works on her idea.

Git allows this collaboration to happen, because with their own versions of the file, Jonny and Sarah can rework their ideal version of the website, completely independent with one another, without messing with the master file. We can see what Jonny’s idea looks like in actuality and avoid making the terrible decision of listening to him. Or, we can try his idea out, then revert the Master back to the old Master format or to Sarah’s Branch when it fails to sell hats, or tanks our Search Rankings.

Some Terms

GitHub is an open source web repository that hosts and stores files and working directories. It’s an online collaborative effort that makes using Git and collaborating with other Git users easy, while protecting information and “Master Files” from corruption or unwanted changes. If you tried to store all versions of a project on the same computer or server, if you run into any issues with that computer, the project is completely fallible. With GitHub, each branch represents a backup up the entire project (a copy of the repository), so it helps backup files and avoid major issues.

Honestly, there are a lot of great things about Git and GitHub, so I won’t be able to fully cover all bells and whistles of the topic in this brief summary. However, I’ll finish off by at least covering the basic concepts for using Git and its terms. I got these definitions from GitHub’s Glossary.

Repository: When you create a project, you are creating a repository. Repositories are essentially like folders for whatever project you are working on. Repositories can be public or private and can have multiple collaborators working on them.

Fork: “A fork is a personal copy of another user’s repository that lives on your account. Forks allow you to freely make changes to a project without affecting the original. Forks remain attached to the original, allowing you to submit a pull request to the original’s author to update with your changes. You can also keep your fork up to date by pulling in updates from the original.”

Fetch: “Fetching refers to getting the latest changes from an online repository (like GitHub.com) without merging them in. Once these changes are fetched you can compare them to your local branches (the code residing on your local machine).”

Branch: “A branch is a parallel version of a repository.” A parallel branch is not the master branch, so you can work and make changes without worrying about messing up the master branch.

Merge: “Merging takes the changes from one branch (in the same repository or from a fork), and applies them into another. This often happens as a Pull Request (which can be thought of as a request to merge), or via the command line.”

Pull/ Pull Request: “Pull refers to when you are fetching in changes and merging them. For instance, if someone has edited the remote file you’re both working on, you’ll want to pull in those changes to your local copy so that it’s up to date… Pull requests are proposed changes to a repository submitted by a user and accepted or rejected by a repository’s collaborators. Like issues, pull requests each have their own discussion forum.”

Push: “ Pushing refers to sending your committed changes to a remote repository such as GitHub.com. For instance, if you change something locally, you’d want to then push those changes so that others may access them.”

Git shows us a shining example of the production that open-source collaborative approaches allow. With GitHub, you have programmers from across the globe working together to help troubleshoot and squash bugs in code. You also have a brilliant library of code chunks you can fork and implement into your own projects. This opens up a ton of possibilities, and makes projects that seem daunting and impossible much more doable.

Dive Deeper — Some E-Learning Materials


Fin

Thank you for reading! If you like this piece, make sure to hit Recommend so others can see it too.

Also, follow the publication Open Source Notes if you want to see what the OSN series looks like so far in action.

If you want to submit your own Open Source Notes articles through the OSN channel on Medium.com, please do! Shoot me an email via: garrett [at] aradiancecollective.com … just include a link to your article, draft or published, and I’ll add your article to the publication.

As always, I appreciate you reading this and I’d be grateful to get your feedback below in the comments.