Repositories

A repository is a storage where all your project and all the changes made to it are kept. You can think of it as a “change database.” But don’t worry; it is only a normal folder on your system, so it is very easy to manipulate.

For each project you want to manage with Git, you have to set up a repository for it. Setting up a repository is very easy. Just navigate to the folder you want to track and tell Git to initiate a repository there.

See? It’s very easy. Let’s convert those statements into commands. But first, let’s open a console to type our commands in. For Linux users, you just have to launch your favorite terminal (Ctrl-Alt-T for Debian like distros). For MacOS, you just have to use Cmd-Space to bring up Spotlight where you can search for the Terminal app. Windows users can open two consoles: cmd and powershell. Powershell is more modern and has UNIX-like commands. To open one of them, use Windows-R and type in the name (cmd or powershell). Note that you need to restart all these consoles on your first installation of Git if you had them open. Git for Windows also comes with a console emulator called Git Bash that provides a similar environment to Linux and Mac consoles. If you use Windows, I highly suggest to use Git Bash so you can have the same experience as other people who use different OSs.

mkdir is a command used to create a directory; it is short for “make directory.” cd is the command used to navigate between directories; it is short for “change directory.” Finally, git init is short for “Git initialize.”

After you initialize the repository, Git will tell you where the database was created like in Figure 3-1 .

Git will create a directory called “.git” that will contain all your changesets and snapshots. If you want to check it out, you will have to show hidden files from your file explorer’s settings. The repository looks like the directory shown in Figure 3-2.

And if you open the .git directory, you will find many more items that are part of the Git database. Check Figure 3-3 for an example.

Remember Chapter 1 that said that instead of tracking changes between versions, Git takes snapshots? Well, all those snapshots are stored in the “.git” directory. Each snapshot is called “commit,” and we’ll look into that shortly after this section.

The HEAD file in this “.git” directory points to the current “branch” or subversion of the project that you are working on. The default branch is called “master,” but it is just like any other branch; the name is just an old convention.

You should also know that initializing is the only way to get a repository. You can copy an entire repository with all its history and snapshots. It is called “cloning,” and we will see that in another chapter.

Working Directory

What about the empty area outside the “.git” directory? It is called the Working Directory, and the files you will be working on will be stored there. Generally, your most recent version will be on the Working Directory.

Each file you work on is on the Working Directory. There is nothing particular about this place except the fact that you will only manipulate the files here directly. Never modify the files inside the “.git” directory!

For example, if we create a new file called README.md in the Working Directory, we will see that Git will know that the project has changed. Make sure that you place your new file alongside the .git directory like in Figure 3-4, not into it!

If we check the status of the Working Directory, we will get a result like the one shown in Figure 3-5.

As you can see in Figure 3-5, we don’t have any commits yet; that’s because we are still on the Working Directory and we haven’t taken any snapshots yet. It also says that we are on the “master” branch; it is the default name for the only branch created on the repository initialization. Then we get the untracked files. Those are the files we modified (in this instance, created).

Essentially, that is the Working Directory: the area where you directly interact with your project files.

Staging Area

The Staging Area is where your files go before the snapshots are taken. Not every file you modified on the Working Directory should be taken into account when taking a snapshot of the current state of the project. Only the files placed in the Staging Area will be snapshotted.

So, before taking a snapshot of the project, you select which changed files to take account of. A change in a file can be creating, deleting, or editing.

It’s that simple. If we wanted to stage the README.md that we created earlier, we would use “git add README.md.” Or if you created multiple files, you can add them one after another or together like “git add file1 file2 file3.”

Adding a file to the staging area won’t produce any visible result, but checking the status will get you a result similar to Figure 3-6.

If you check out Figure 3-6, you will notice that after staging the file, the Working Directory is clean again. That’s because “git status” only keeps track on “unstaged” files (edited files that have not been marked for a snapshot).

After you stage all the files that you want the changes to be taken into account, you are now ready to take your first snapshot!

Commits

Like we talked about in the section before this one, a commit is just a snapshot of the entire project at a certain time. Git doesn’t record the individual changes done to the files; it takes a picture of the entire project.

In addition to the snapshot, a commit also contains information about the “author” of the content and the “commiter” or who put the changeset into the repository.

Since a commit is a snapshot from the state of the project, the previous state of the project is another commit called “parent.” The very first commit is created by Git when the repository is created, and it’s the one commit that has no parents. All future commits are then linked to each other via parentage. The ensemble of those commits that are parents to each other is called “branch.”

A commit is identified by its name, a 40-character string that is obtained by hashing the commit. It is a simple SHA1 hash so multiple commits with the same information will have the same name.

A reference to a specific commit is called “head,” and it also has a name. And the head you are currently working on is called “HEAD” (see the previous section).

We can now commit the files we staged earlier. Before each commit, you should check the status of the Working Directory and the Staging Area. If all the files you want to commit are in the Staging Area (under the phrase “Changes to be committed”), you can commit. If not, you have to stage them with “git add.”

If we execute this command, it will open our default editor (check Chapter 2 if you want to modify yours) and ask us for a commit message. A commit message is a short description of what has changed in the commit compared to the previous one.

My default editor is Vim, so if I execute the commit command, I will see a screen as shown in Figure 3-7.

You can see in Figure 3-7 that the first line of the file is empty; that’s where you have to write the commit message. The commit message should be written on one line, but you can always add more lines of comments. Comments start with “#” and are ignored by Git; they are only used to complete the commit message, to make it clearer. Also note that Git puts automatically the list of changed files in the commit comments (the same files you saw with “git status”).

You will learn the proper way to write commit messages the right way in the later chapters. But for now, just enter a simple message like “Add README.md to the project” on the first blank line like in Figure 3-8.

After you wrote your commit message like in Figure 3-8, you can close the editor (after saving!). You will then get a summary of the commit like in Figure 3-9.

We took our first snapshot! If you check the status of the repository, you can see that it is clean again, unless you left some files unstaged.

Quick start with Git

So, now that you are familiar with the basic concept of Git, we are going to apply them in a real project. Let’s imagine you want to create a folder to hold your TODO list and want it to be versioned so you can check when each item was completed.

To get you more familiar with Git, you will be doing the next exercise without any help. If you get stuck, just check the previous sections for directions.

Don’t forget to put the files you modified on the Staging Area before committing or they won’t be part of the snapshot. The modified files you didn’t put on the Staging Area will just stay on the Working Directory until you decide to discard them or include them in a future commit.

Let’s get started on the exercise! Please complete it until the end and don’t move on to the next chapter until you understand clearly how Git works.

If you don’t have too many problems understanding those concepts, you are ready for more Git commands and concepts.

Summary

If a file was part of the previous commit and you didn’t modify them, they will automatically be part of the next commit. A modified but unstaged file is considered as unmodified. You have to ask Git to track them by staging those files.

We also learned a little bit about committing and commit messages. Opening an external editor to write commit messages might be a little awkward at first, but you will eventually get the hang of it after some time.

In the next chapter, we will learn how to check the project history and navigate between versions. We will also learn about ignoring certain files and show the current changes done to the project since the last commit.