Get Started with Git

Based on its popularity, it’s likely that you may have heard of Git. By definition, Git is a distributed revision control and source code management system (SCM).

Put simply, Git helps you to save projects at different versions so that you can retrieve previous versions without any problem. Source codes (or files) are saved in repositories. You check out the files from a version, make some changes, save it, and commit changes to create a newer version of your project.

We sat down with Richo Healey of 99 Designs to discuss the many uses for Git. Watch below as he introduces us to some of the top-level stuff as well as how the database works. It’s not as scary as most people make it out!

Do you use Git for it’s conventional source code management? Have you seen or heard of any unconventional yet useful applications for Git?

Jess: I’m here with Richo Healey, who is a dev ops engineer at 99designs. He is going to tell us a little bit about Git today. What exactly is Git?

Rich: Put simply, Git is referred to as the Global Information Tracker. It’s basically an elaborate key value store for complex data types that can all be resolved down to plain text. What this means in real world terms for you is that if you have a large collection of objects that you want to transition through a series of states, you can use Git to track those states with awesome delta compression on disk and complete history of it.

Jess: So what are Git’s origins? When did it start, how did it come to life?

Rich: Originally, Linux was using a piece of software called BitKeeper for managing dead source code and the version metadata associated with it, but due to some licensing constraints they basically had an enormous falling-out with the company that were publishing BitKeeper. Then Linus Torvalds set off to write his own implementation that would hopefully solve all the problems he saw in existing solutions at that point.

Jess: I understand there’s third-party usages for this. What exactly are they?

Rich: GitHub certainly popularized using Git. They’ve got ludicrous usage numbers these days in terms of just the sheer number of developers using it. But on the back of that popularity, a lot of services like Heroku for application hosting or Travis CI, for example, for automated testing will basically integrate natively with Git and catch the events that you’re propagating to third-party repos, meaning that you don’t have to go through and execute these extra steps on top of your ordinary workload. Git internalizes that so that when you’re just pushing code so that you have a record of it, you can actually integrate that deployment or testing step along side it.

Jess: What are some of the use cases for Git outside of just being a means of storing code?

Rich: Git is totally agnostic to the data that it’s storing, which means that while it lends itself obviously to storing swathes of source code, it also lends itself to, for example, a university student writing their PhD thesis because of its ability to track content throughout many revisions. It means that as you’re writing a living document, you can then go over and browse the history of it as well as what you were thinking at the time in the form of commit messages.

At the opposite end of the scale, there’s been a recent movement towards governments using it for writing their laws. Because of its forking and branching model and the way it allows you to make changes to something else and then propose your changes as a better revision to what they already have, it lends itself really neatly to that.

Jess: So do you need to be tech-savvy to use Git, or can anybody really use it?

Rich: I think you’ll find that the proficiency that you need to interact with Git varies almost directly to what you’re trying to do with it. If you’re looking to store all of your source code, you would need a reasonable amount of technical proficiency. But if you’re a programmer, you probably already have that.

At the other end of the scale, since we translated 99 Designs into German, we actually have our copy translators interacting directly with our source code via an editor. What that editor does is basically means that they don’t need to directly understand what’s going on. They just push their changes and it finds its way back into our repository.

Jess: So where do we get started if we want to learn more about Git?

Rich: Scott Chacon, who founded GitHub, who have made enormous strides in popularizing Git actually wrote a book called Pro Git, which is available on Amazon but also free on open-source if you just want to view the content. As well as GitHub publishing some fantastic help pages and an interactive demo which will actually let you interact with a Git database right inside your browser.

Jess: How do you feel about introducing us to Git? Will you show us around?

Rich: Sure, I’d love to show you some of the top-level stuff as well as some of how the database works and how it’s not as scary as most people make it out.

Jess: Let’s check it out.

Rich: In introducing Git, I wanted to quickly walk you through some of the features that separate it from traditionally centralized SCMs and then dive into one of the things that makes it the most bad-ass, rebasing, which is also considered one of the most frightening techniques. To start off, we’re just going to clone agent99, the deploy bot that we use at 99designs. Moving into this new repo, you can immediately see that it has the full history as shown by Git log. This is obviously different SVN where fetching the log would involve going back to the server, and would take such a long time that you’d almost certainly need to specify a revision range that you’re interested in. This is significantly more convenient if you’re trying to work on the road, disconnected from the

Internet.

The next thing I wanted to discuss, as I said, was rebase. Rebase is basically the ability to automatically or interactively re-write history in a Git repo. It’s enormously useful if you have a workflow that involves committing very often, as in minutely intervals and then at the end of a body of work trying to convert it into logical blocks of work. This can make it a lot easier to find mistakes that you’ve made.

For example, if you’re using Git Bisect. To show a trivial example of this, I’m going to show you a commit that I may have regretted, with take, where I’ve bumped this stable ruby version that I’m targeting inside Agent 99. Removing it is trivial. We’re going to rebase back a few commits from head, simply remove the commit that we no longer want, and then close.

As you can see, the commit’s now gone. That’s just one trivial example. At some point, I’d like to walk you through some more advanced ones.

Jess: Thanks so much, Richo. This has been Jess Genevieve Brown for Learnable.com.