What Is Git? An Explainer

​GitHub is becoming an oddly popular place given its role as a vast storehouse of oft inscrutable computer code and technical information. It makes sense though, as programming itself is integrating itself into pop culture in wholly unexpected ways so too should one of its most crucial meeting grounds. Thus, it seems like an opportune time to talk about what ​Git actually is, as one of the most powerful shadow technologies in computer science.

Allow me to rave for a moment. Git is awesome, one of the more profound and useful tools in programming even. Git is also weird and kind of confusing if one doesn't happen to be directly involved in code and the processes behind code production and the difficulties of managing potentially hundreds of files being worked on by just as many programmers and engineers.

First of all, GitHub is not Git. I see this confusion a lot. GitHub is a place on the internet for storing the files and file structures organized according to the Git system. The Git system is a type of version control, surveilling your stuff for updates and deletions and making sure you or someone else on your project doesn't do anything stupid. It watches your files for changes and allows for even simple programming projects of one or two files to be shared among large amounts of people. It does this almost invisibly.

I use Git all the time without "pushing" (which is like uploading) my documents to GitHub. My Git repository (a collection of files usually pertaining to one project) in that case is just on my hard drive.

The utility of Git is in branching and merging documents. If I have a project with a dozen files that are all interdependent on each other in crucial ways, making edits to any of those files becomes something of a risky business, particularly if other people happen to be working on those files too, and even more so if the project is "live" as a website. Last week, I was working on a kind of dump map thing that was a part of a website and I wanted to add a cool new feature, but the site couldn't be disrupted. I made a branch of the project, worked on it, tested and tried to break it a bunch of times, and then, once satisfied, I merged it with the master and replaced the files on the server.

So, instead of working on the main "master" version, I check out a clone of the master version. I can screw around with this all I like without it interfering with the master documents and when it's totally ready, I (or we) can take my changes and merge them with the master project. So, in a sense it's just a way of saving things in an alternate universe.

Git was created by Linus Torvalds, of Linux fame. He needed something reasonably quick that could handle the near-constant barrage of activity involved in working on something like Linux. It also needed to be free. Not being able to find it, he created Git. Like Linux, Torvalds named it after him​self; in British slang, Git means one that is "pig headed, think[s] they are always correct, argumentative," according to the Git WIki.

The thing that really makes Git work is in its ability to detect changes to files—not just that a change has occurred, but where and what change occurred. A Git tracked file has its contents hashed using the SHA-​1 encryption algorithm, resulting in a 40 (hex) character blob. When this blob is different than the last blob Git observed, it registers the file as "modified" and the developer can proceed accordingly (committing the changes to the master or whatever).

All of this seems really simple, and it manages to stay that simple as projects grow enormously. Thanks again, Linus.