Overview of Git

Git is a dis­trib­uted ver­sion con­trol sys­tem that is most known for being fast and decen­tral­ized. It has many sim­i­lar­i­ties to Sub­ver­sion as far as work­flows goes but dif­fers great­ly under the hood. 

But let’s zoom out for a moment and look at the big pic­ture. If you’re already famil­iar with ver­sion con­trol sys­tems then you can skip on to the next sec­tion. If you’re still won­der­ing why a VCS real­ly mat­ters: keep reading.

The Big Picture

When start­ing out with Git, it’s much eas­i­er to learn how to use it if we also under­stand the basics of what Git is try­ing to do.

By that I mean what Git is beyond the com­mands. Con­cep­tu­al­ly speaking.

What is a Ver­sion Con­trol Sys­tem (VCS)

Git is a ver­sion con­trol sys­tem. You’ll hear this referred to as a VCS some­times. This is a gen­er­al term to describe tools that track changes to ​“a file or set of files” over a peri­od of time. The rea­son we track the changes is so we can revert to pre­vi­ous ver­sions, have a log of the work that was com­plet­ed, as well as have an incre­men­tal back­up of the project.

Ver­sion con­trol sys­tems aren’t just for code but that’s where they got their start and are most wide­ly used.

You could use ver­sion con­trol for a book you’re writ­ing. My first book was writ­ten in a Word doc­u­ment but my sec­ond I wrote in a code edi­tor and used ver­sion control.

You could use ver­sion con­trol for designs you’re cre­at­ing for a project. You could use ver­sion con­trol for a series of doc­u­ments, like pro­pos­als, con­tracts, or agreements.

If it’s a file, it can be tracked by a ver­sion con­trol system.

Why use a ver­sion con­trol sys­tem for your projects?

First and fore­most is because it’s a reli­able way to track changes to your files. You might’ve used a sim­ple ver­sion con­trol sys­tem in the past where you zipped up a project and put a date on it, there­by cap­tur­ing that day’s work. 

A ver­sion con­trol sys­tem also lets you snap­shot changes to the project but in a more struc­tured and reli­able way that makes it easy to merge two dif­fer­ent ver­sions (branch­es) of the project or revert back to a pre­vi­ous version.

Get­ting Git

There are lot of oth­er ver­sion con­trol sys­tems out there and per­haps you’ve used one or two before. In the past I’ve used CVS, Sub­ver­sion, and Mer­cu­r­ial, in addi­tion to Git. I pre­fer Git because it is local, sim­ple, and fast.

So let’s talk briefly and at a high lev­el of how Git works.

Snap­shots of Your Project

When you ini­tial­ize a new Git repos­i­to­ry, you are telling Git to track a set of files. 

This set of files will be in a com­mon direc­to­ry (and subdirectories). 

Git now cares about what hap­pens to those files. At first Git will just tell you that it sees a bunch of files but isn’t yet track­ing them. It’ll be up to you to add those files so Git will care about hem on an indi­vid­ual basis. After that, Git will notice every change to the file.

By ini­tial­iz­ing a Git repos­i­to­ry, you tell Git: 

“Hey I want you to pay atten­tion to this set of files. If you don’t know about a file yet, please tell me. If some­thing changes in a file, please tell me. In return, I’ll com­mit those changes to your repos­i­to­ry so you are aware.”

Let me try an anal­o­gy and see if this works.

Imag­ine you’re a sum­mer camp coun­selor. Your job is to take care of, edu­cate, and oth­er­wise enter­tain a spe­cif­ic group of kids. The kids are orga­nized into groups.

You arrive at the camp on Day 1 and you know you’re respon­si­ble for a group of kids. You walk into the room and your super­vi­sor says: 

“Okay, Ryan, this is your group.”

You look out at the group of kids and say:

“Okay, ya’ll are mine. I will take care of you.”

“First order of busi­ness. I see I have 15 kids here. But I don’t know your names. I need you to form a line and then give me your names so I can write them on this paper and make a list. This is the list I will use to track your progress at camp so I can report back to your par­ents when they pick you up on Sunday.”

The kids form a line and, one by one, they give you their name and you write it down on the paper attached to your clip­board. You now have them tracked and know exact­ly who the kids are.

As sum­mer camp goes on, you watch your campers and their activities. 

If Suzanne swims a 1 kilo­me­ter lap in the lake, you mark that change down next to her name on the list.

If Albert gets sick because he ate too many bowls of choco­late pud­ding after din­ner, then you mark that down next to his name to track his health.

The bot­tom line is: you are watch­ing these kids and track­ing how they change dur­ing their time at camp.

This anal­o­gy may be a lit­tle thin but I hope you get the idea. 

Think about Git as a sys­tem that watch­es a set of files you tell it to. Every time you make a change to a file and com­mit that change (record it as a change), Git snap­shots the state of the entire col­lec­tion of files at that moment. 

This might sound like Git is just zip­ping up the files and such. It’s much more nuanced than that (and it’s some­thing we cov­er in depth lat­er on). How­ev­er, Git only saves and records changes to the files that have changed. For the oth­er files, the snap­shot sim­ply points to the pre­vi­ous snap­shot. This allows Git to effi­cient­ly store files with­out becom­ing unnec­es­sar­i­ly large over the life­cy­cle of a project.

So, what is Git doing? It’s car­ing about your project files because you told it to. Every time you work with Git think of it in this way. Git cares a lot and some­times you have to tell it no longer care (using a .gitignore file), too.

As you’ll learn lat­er on merg­ing branch­es in Git, Git cares so much that it won’t let you lose changes or work. It real­ly is look­ing out for you.

With a big pic­ture out of the way, let’s get a brief his­to­ry les­son before we jump into doing some work with Git.