GIT: The Big Picture of Git

When starting out with Git, it’s much easier to understand how to use it if we also understand the basics of what Git is.

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 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–and I have–use version control for a book you’re writing.

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.

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

Getting Git

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 them 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 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 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 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. Key takeaway: Think about Git as a system that watches 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 introduce it to each file.

This is the git add command.

Just like with the campers and and counselor, think about your Git repository as the set of files. 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. 

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

And, as you’ll learn in a different video 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.

GIT: What is a bare Git repository?

The standard way of initializing a new Git repository is to run git init. The directory in which you do this will be become the Working Tree for the repository.

As part of the initialization process, Git creates a .git directory (which his hidden by default because of the . in the name) that contains the repository itself. This is brains of the repository; it's where Git tracks your changes, stores commit objects, refs, etc. You probably only rarely interact with that hidden directory.

Okay, so all of this is to lay the groundwork for understanding a bare Git repository. What the heck is it?

A bare Git repository is a repository that is created without a Working Tree. Go ahead and create one to see.

git init --bare .

Run ls on that directory and you won't see a Working Tree but just the contents of what is typically in the .git directory.

Why this setup?

A bare Git repository is typically used as a Remote Repository that is sharing a repository among several different people. You don't do work right inside the remote repository so there's no Working Tree (the files in your project that you edit), just bare repository data.

And that's it.

GIT: Starting with an Unversioned Project

Let's start with an existing project that is not yet under version control. Change into the project's root folder on the command line and use the "git init" command to start versioning this project:

$ cd path/to/project/folder
$ git init

Now take a moment to look at the files in that directory (including any hidden files):

$ ls -la

You'll see that a new, hidden folder was added, named ".git". All that happened is that Git created an empty local repository for us. Please mind the word "empty": Git did notadd the current content of your working copy as something like an "initial version". The repository contains not a single version of your project, yet.

GLOSSARY

Working Copy

The root folder of your project is often called the "working copy" (or "working directory"). It's the directory on your local computer that contains your project's files.

You can always ask the version control system to populate your working copy with any version of your project. But you always only have one working copy with one specific version on your disk - not multiple in parallel.

Ignoring Files

Typically, in every project and on every platform, there are a couple of files that you don't want to be version controlled: on Mac OS, e.g., those pesky ".DS_Store" files aren't worth versioning. In other projects, you might have build or cache files that make no sense in a version control system. You'll have to decide yourself which files you don't want to include.

NOTE

Which Files Should I Ignore?

As a simple rule of thumb you'll most likely want to ignore files that were created automatically (as a "by-product"): temporary files, logs, cache files...

Other examples for excluded files range from compiled sources to files that contain passwords or personal configurations.

A helpful compilation of ignore rules for different projects and platforms can be found here: github.com/github/gitignore

The list of files to ignore is kept in a simple file called ".gitignore" in the root folder of your project. It's highly recommended to define this list at the very beginning of your project - before making your first commit. Because once files are committed, you'll have to jump through some hoops to get them out of version control, again.

Now, let's get going: Create an empty file in your favorite editor and save it as ".gitignore" in your project's root folder. If you're on a Mac, e.g., you'll want to make sure it contains at least the following line:

.DS_Store

If there are other files you want to ignore, simply add a line for each one. Defining these rules can get quite complex. Therefore, to keep things simple, I'll list the most useful patterns which you can easily adapt to your own needs:

• Ignore one specific file: Provide the full path to the file, seen from the root folder of your project.
  path/to/file.ext
• Ignore all files with a certain name (anywhere in the project): Just write down the file's name, without giving a path.
  filename.ext
• Ignore all files of a certain type (anywhere in the project):
  *.ext
• Ignore all files in a certain folder:
  path/to/folder/*

Making Your First Commit

With some ignore rules in place, it's time to make our initial commit for this project. We'll go into great detail about the whole process of committing a little later in this book. For now, simply execute the following commands:

$ git add -A
$ git commit -m "Initial commit"

GIT: How to create a local git repository with existing code base?

$ cd /path/to/my/codebase

$ git init <1>

$ git add . <2>