How Git stores objects - Why You Should Know This

The Big Idea

Discover how Git's clever storage saves your work like magic, so you never lose a change again!

The Scenario

Imagine you are saving every version of your project files by copying them into separate folders manually every time you make a change.

You have to remember where each version is, and it quickly becomes a huge mess.

The Problem

This manual way is slow and confusing.

You might lose track of which file version is the latest or accidentally overwrite something important.

It wastes time and causes stress when you want to find or restore an old version.

The Solution

Git stores your project files as objects in a smart way.

It saves only the changes and links them together, so you can easily find any version without copying everything again.

This makes managing versions fast, safe, and organized.

Before vs After

✗ Before

cp -r project_v1 project_backup_1
cp -r project_v2 project_backup_2

✓ After

git add .
git commit -m "Save changes"

What It Enables

Git lets you track and restore any change instantly, making teamwork and project history simple and reliable.

Real Life Example

When a team works on a website, Git stores each developer's changes as objects, so they can merge work without losing anything.

Key Takeaways

Manual copying of versions is slow and error-prone.

Git stores files as objects, saving space and linking changes.

This makes version control fast, safe, and easy to use.

Practice

1. What type of Git object stores the actual content of a file?

easy

A. Blob

B. Tree

C. Commit

D. Tag

Solution

1. Step 1: Understand Git object types

   Git stores data in objects: blobs for file content, trees for directories, commits for snapshots, and tags for references.

2. Step 2: Identify the object for file content

   The blob object specifically holds the content of files, not metadata or history.

3. Final Answer:

   Blob -> Option A

4. Quick Check:

   File content = Blob [OK]

Hint: Remember: Blob = file content, Tree = folder [OK]

Common Mistakes:

• Confusing tree with blob
• Thinking commit stores file content
• Assuming tag stores file data

2. Which command correctly shows the type of a Git object given its hash abc123?

easy

A. git object-type abc123

B. git show-type abc123

C. git cat-file -t abc123

D. git object -show abc123

Solution

1. Step 1: Recall Git commands for object info

   The command git cat-file is used to inspect Git objects. The -t option shows the object type.

2. Step 2: Match the correct syntax

   git cat-file -t abc123 correctly shows the type of the object with hash abc123. Other options are invalid commands.

3. Final Answer:

   git cat-file -t abc123 -> Option C

4. Quick Check:

   Show object type = git cat-file -t [OK]

Hint: Use git cat-file -t to check object type fast [OK]

Common Mistakes:

• Using git show-type which doesn't exist
• Confusing git object commands
• Forgetting the -t option

3. Given a Git commit object hash def456, what will the command git cat-file -p def456 display?

medium

A. The raw content of a file stored in the commit

B. The list of branches containing the commit

C. The tags pointing to this commit

D. The commit message, author info, and tree hash

Solution

1. Step 1: Understand what a commit object contains

   A commit object stores metadata: author, date, commit message, and a tree hash representing the snapshot of files.

2. Step 2: Interpret git cat-file -p output for commit

   The command git cat-file -p pretty-prints the commit object, showing its message, author info, and tree hash, not raw file content or branch/tag info.

3. Final Answer:

   The commit message, author info, and tree hash -> Option D

4. Quick Check:

   Commit object details = message + author + tree [OK]

Hint: Commit object shows metadata, not file content [OK]

Common Mistakes:

• Expecting file content from commit object
• Confusing branches or tags with commit data
• Thinking commit object lists branches

4. You run git cat-file -p 123abc but get an error: fatal: Not a valid object name 123abc. What is the most likely cause?

medium

A. The command syntax is incorrect

B. The hash 123abc does not exist in the repository

C. You need to add files before using git cat-file

D. The repository is corrupted

Solution

1. Step 1: Analyze the error message

   The error says the object name is invalid, meaning Git cannot find an object with hash 123abc.

2. Step 2: Check common causes

   This usually happens if the hash is wrong or does not exist. The command syntax is correct, and adding files is unrelated. Repository corruption is less common and would cause other errors.

3. Final Answer:

   The hash 123abc does not exist in the repository -> Option B

4. Quick Check:

   Invalid object name = missing hash [OK]

Hint: Check if object hash exists before using git cat-file [OK]

Common Mistakes:

• Assuming syntax error instead of missing object
• Thinking files must be added before cat-file
• Jumping to repository corruption conclusion

5. You want to find the SHA-1 hash of a file's content before committing. Which Git command sequence correctly creates the object and shows its hash without committing?

hard

A. git hash-object -w <file> && git cat-file -p <hash>

B. git commit -m 'temp' && git show <file>

C. git add <file> && git log --hash

D. git init && git status

Solution

1. Step 1: Understand git hash-object usage

   The command git hash-object -w <file> creates a blob object from the file content and writes it to the object database, returning its hash.

2. Step 2: Verify object content with git cat-file

   Using git cat-file -p <hash> shows the content of the created blob object, confirming the hash matches the file content.

3. Final Answer:

   git hash-object -w <file> && git cat-file -p <hash> -> Option A

4. Quick Check:

   hash-object -w creates blob and shows hash [OK]

Hint: Use git hash-object -w to create and get file hash [OK]

Common Mistakes:

• Using git commit before hashing
• Confusing git add with hashing
• Thinking git init shows file hash