10.1 Git Internal Principles – Low-level commands and high-level commands

Whether you skip ahead to this chapter or finish reading the rest of the chapters and get to this point — you’ll get a look at the inner workings and implementation of Git in this chapter. We’ve found that learning this section is crucial to understanding how useful and powerful Git is. However, some argue that the content may be too difficult and complex for beginners to understand. So we put this in the last chapter, and you can either read it first or later, depending on yourself.

Anyway, now that we’ve read this far, let’s get started. First of all, Git is fundamentally a content-Addressable file system that provides a user interface for a version control system on top of it. You’ll learn what that means in a second.

The user interface in the early days of Git (primarily pre-1.5) was much more complex than it is today, as it was more focused on being a file system rather than a polished version control system. Every now and then there are cliches complaining about the arcane and complex Git user interface of the early days; In recent years, however, it has been improved to be as clear and easy to use as any other version control system.

The content-addressing file system layer is a pretty cool set of things, so we’ll cover that first in this chapter. Then we’ll look at transport mechanisms and repository management tasks — you’ll have to deal with them sooner or later.

Low-level commands and high-level commands

The purpose of this book is to discuss how to play with Git through checkout, branch, remote, and about 30 other commands using these verbs. However, because Git was originally a toolset for a version control system, rather than a complete, user-friendly version control system, it also includes a subset of commands to do the underlying work. These commands are designed to be linked together in UNIX command-line style or invoked by scripts to do the job. This part of the command is often called a “plumbing” command, while the friendlier command is called a “porcelain” command.

The first nine chapters of the book are devoted to high-level command. In this chapter, however, we will focus on low-level commands. Because the underlying commands give you a peek into Git’s inner workings, they also help explain how Git does its job and why it works the way it does. Most low-level commands are not intended for the end user: they are better suited as part of new commands and custom scripts.

When you execute git init in a new or existing directory, git creates a.git directory. This directory contains almost all the objects that Git stores and manipulates. If you want to back up or copy a repository, simply copy the directory to another location. Everything discussed in this chapter is located in this directory. The structure of this directory is as follows:

$ ls -F1
HEAD
config*
description
hooks/
info/
objects/
refs/Copy the code

There may be other files in this directory, but for a brand new Git init repository, this is the default structure you’ll see. The Description file is for use only by GitWeb applications, so we don’t need to worry about it. The config file contains project-specific configuration options. The info directory contains a global exclude file that places ignored patterns that do not want to be recorded in the.gitignore file. The hooks directory contains client-side or server-side hook scripts, a topic discussed in detail in Git hooks.

The remaining four items are important: the HEAD file, the index file (yet to be created), and the Objects and refs directories. These entries are a core part of Git. The Objects directory stores all data content; The refs directory stores Pointers to submitted objects of data (branches); The HEAD file indicates which branch is currently being checked out; The index file holds the staging area information. We’ll examine each of these four sections in detail to understand how Git works.

prev
next