Overview of Git
Git is a distributed version control system that is most known for being fast and decentralized. It has many similarities to Subversion as far as workflows goes but differs greatly under the hood.
But let’s zoom out for a moment and look at the big picture. If you’re already familiar with version control systems then you can skip on to the next section. If you’re still wondering why a VCS really matters: keep reading.
The Big Picture
When starting out with Git, it’s much easier to learn how to use it if we also understand the basics of what Git is trying to do.
By that I mean what Git is beyond the commands. Conceptually speaking.
What is a Version Control System (VCS)
Git is a version control system. You’ll hear this referred to as a VCS sometimes. This is a general term to describe tools that track changes to “a file or set of files” over a period of time. The reason we track the changes is so we can revert to previous versions, have a log of the work that was completed, as well as have an incremental backup of the project.
Version control systems aren’t just for code but that’s where they got their start and are most widely used.
You could use version control for a book you’re writing. My first book was written in a Word document but my second I wrote in a code editor and used version control.
You could use version control for designs you’re creating for a project. You could use version control for a series of documents, like proposals, contracts, or agreements.
If it’s a file, it can be tracked by a version control system.
Why use a version control system for your projects?
First and foremost is because it’s a reliable way to track changes to your files. You might’ve used a simple version control system in the past where you zipped up a project and put a date on it, thereby capturing that day’s work.
A version control system also lets you snapshot changes to the project but in a more structured and reliable way that makes it easy to merge two different versions (branches) of the project or revert back to a previous version.
There are lot of other version control systems out there and perhaps you’ve used one or two before. In the past I’ve used CVS, Subversion, and Mercurial, in addition to Git. I prefer Git because it is local, simple, and fast.
So let’s talk briefly and at a high level of how Git works.
Snapshots of Your Project
When you initialize a new Git repository, you are telling Git to track a set of files.
This set of files will be in a common directory (and subdirectories).
Git now cares about what happens to those files. At first Git will just tell you that it sees a bunch of files but isn’t yet tracking them. It’ll be up to you to add those files so Git will care about hem on an individual basis. After that, Git will notice every change to the file.
By initializing a Git repository, you tell Git:
“Hey I want you to pay attention to this set of files. If you don’t know about a file yet, please tell me. If something changes in a file, please tell me. In return, I’ll commit those changes to your repository so you are aware.”
Let me try an analogy and see if this works.
Imagine you’re a summer camp counselor. Your job is to take care of, educate, and otherwise entertain a specific group of kids. The kids are organized into groups.
You arrive at the camp on Day 1 and you know you’re responsible for a group of kids. You walk into the room and your supervisor 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 business. 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 parents 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 clipboard. You now have them tracked and know exactly who the kids are.
As summer camp goes on, you watch your campers and their activities.
If Suzanne swims a 1 kilometer 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 chocolate pudding after dinner, then you mark that down next to his name to track his health.
The bottom line is: you are watching these kids and tracking how they change during their time at camp.
This analogy may be a little thin but I hope you get the idea.
Think about Git as a system that watches a set of files you tell it to. Every time you make a change to a file and commit that change (record it as a change), Git snapshots the state of the entire collection of files at that moment.
This might sound like Git is just zipping up the files and such. It’s much more nuanced than that (and it’s something we cover in depth later on). However, Git only saves and records changes to the files that have changed. For the other files, the snapshot simply points to the previous snapshot. This allows Git to efficiently store files without becoming unnecessarily large over the lifecycle of a project.
So, what is Git doing? It’s caring 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 sometimes you have to tell it no longer care (using a
.gitignore file), too.
As you’ll learn later on merging branches in Git, Git cares so much that it won’t let you lose changes or work. It really is looking out for you.
With a big picture out of the way, let’s get a brief history lesson before we jump into doing some work with Git.