Mastering git, Part 17, git repository layout and Git Objects

1. The .git Directory

When you initialize a new Git repository with git init, Git creates a .git directory in your project. This directory is where almost all of the information that Git needs and uses is stored. It includes:

• Objects: The objects directory stores all the content of your files, but in a format that Git uses internally, not the original raw files.
• Refs: The refs directory holds pointers to commit objects (essentially, the tips of branches and tags).
• HEAD: The HEAD file points to the currently checked out commit/branch.
• Index: The index file (also known as the staging area) keeps track of what will go into your next commit.

2. Git Objects

Git uses a few primary types of objects:

• Blobs: These store the contents of your files. Each version of a file is represented by its own blob.
• Trees: These represent the structure of your directory. They point to blobs and other trees (subdirectories).
• Commits: Commit objects point to a tree object representing the top-level directory for that commit, the parent commit(s), author/committer information, and a commit message.

3. Commits and Trees

When you make a commit with git commit, Git does the following:

1. Creates Blob Objects: For each file in the staging area, Git creates a blob object and stores it in the .git/objects directory.
2. Creates a Tree Object: Git then creates a tree object using the information about the file structure at the time of the commit.
3. Creates a Commit Object: Finally, a commit object is created pointing to the tree object, parent commit, and containing the commit message.

4. Branching and Merging

• Branches: A branch in Git is simply a lightweight movable pointer to one of these commits. The default branch name in Git is master.
• Merging: When you merge two branches, Git uses the information in the commit objects to integrate the changes.

5. The Staging Area and Your Workflow

• Add to Staging Area: When you git add files, you are adding snapshots of those files to the staging area (index).
• Committing: git commit takes the files as they are in the index and stores that snapshot permanently to your Git directory.

6. Git’s Integrity

• SHA-1 Hashes: Every object in Git is checksummed with a SHA-1 hash before it is stored and is then referred to by that hash. This ensures the integrity of your data.

7. Remote Repositories

• Cloning and Pushing: When you clone a repository, Git creates a copy of all the data that the server has at that time. When you push or pull changes, only the necessary changes are transferred.

More ob Blobs and Objects:

Blobs

1. Definition:

   • A blob (binary large object) is the most basic data storage object in Git. It stores the contents of a file, but not its metadata (like its name, path, or size).

2. Characteristics:

   • Content Addressable: Each blob is identified by a SHA-1 hash of its contents. This means identical file contents will always generate the same blob identifier, regardless of the file’s name or location.
   • Immutable: Once created, a blob object does not change. If the file contents change, a new blob is created for the new version.
   • No Filename: Blobs do not store the filename or the file path. They only contain the file content.

3. Usage:

   • When you stage a file using git add, Git creates a blob object from the contents of that file.
   • The blob is then compressed and stored in the .git/objects directory.

4. Example:

   • If you have a text file with the content "Hello, Git!", Git will create a blob object for this text. The blob will only contain "Hello, Git!" and its SHA-1 hash would be based on this content.

Trees

1. Definition:

   • A tree object in Git represents a directory. It contains a list of file names and modes along with references to blob and tree objects.

2. Characteristics:

   • Structure Representation: Trees correspond to directory entries. Each entry in a tree object can be either another tree (subdirectory) or a blob (file).
   • SHA-1 Hashes: Like blobs, trees are also identified by SHA-1 hashes, derived from their contents.
   • Nested Trees: Trees can reference other trees, allowing Git to represent a directory with subdirectories.

3. Usage:

   • When you commit, Git creates a tree object that represents the state of the directory (or directories) being tracked.
   • The tree object references the blobs for files in the directory and other trees for its subdirectories.

4. Example:

   • Consider a directory with two files, file1.txt and file2.txt. When you commit this directory, Git creates a tree object. This tree object will have entries for both file1.txt and file2.txt, each pointing to their respective blobs.

How Blobs and Trees Work Together

• Committing: When you commit, Git takes the state of your staging area (index) and creates tree objects that represent the directory structure of your project. Each tree object points to other trees and blobs based on the current project structure.
• Browsing History: When you browse the history of your repository using commands like git log or git show, Git uses the tree and blob objects to reconstruct the file and directory states at each commit.

Understanding blobs and trees is key to understanding how Git manages data. Essentially, blobs store the content of your files, while trees represent the structure of your directories, linking everything together in a coherent and efficient manner.