The Big Picture of Git

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

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 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 — and I have — use ver­sion con­trol for a book you’re writing. 

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.

Okay, great. So why should 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.

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 them 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 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 actives. If Suzanne swims a 1km 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. Key take­away: Think about Git as a sys­tem that watch­es a set of files you tell it to. 

This is the git init command.

Once you tell it to watch a set of files, you then have to intro­duce it to each file.

This is the git add command.

(I go over the actu­al com­mands in my Up and Run­nig with Git course.)

Just like with the campers and and coun­selor, think about your Git repos­i­to­ry as the set of files. 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 the Git: Under the Hood course).

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 (git ignore), too.

And, as you’ll learn in a dif­fer­ent video 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.