Git LFS for large files - Step-by-Step Execution

Process Flow - Git LFS for large files

Start: Large file in project

↓

Track file with Git LFS

↓

Add file to Git index

↓

Commit changes

↓

Push to remote repository

↓

Large file stored in LFS server

↓

Pointer file stored in Git repo

This flow shows how Git LFS tracks large files by replacing them with small pointer files in Git, while storing the actual large files on a separate server.

Execution Sample

Git

git lfs track "*.psd"
git add .gitattributes
git add bigfile.psd
git commit -m "Add large PSD file"
git push origin main

This sequence tracks PSD files with Git LFS, adds the tracking config, stages the large file, commits, and pushes to remote.

Process Table

Step	Command	Action	Result
1	git lfs track "*.psd"	Add pattern to .gitattributes	Files matching *.psd tracked by LFS
2	git add .gitattributes	Stage .gitattributes file	.gitattributes ready to commit
3	git add bigfile.psd	Stage large PSD file	Pointer file staged instead of full file
4	git commit -m "Add large PSD file"	Commit changes	Commit includes pointer and .gitattributes
5	git push origin main	Push commit and LFS objects	Pointer pushed to Git repo; large file pushed to LFS server
6			Execution ends: large file stored separately, Git repo has pointer

💡 Push completes with large file stored on LFS server and pointer in Git repository

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	After Step 5
.gitattributes	empty	contains '*.psd filter=lfs diff=lfs merge=lfs -text'	staged	staged	committed	committed
bigfile.psd	untracked	untracked	untracked	staged as pointer	committed as pointer	pushed to LFS server
Git commit	none	none	none	none	created with pointer	pushed
LFS server	empty	empty	empty	empty	empty	large file stored

Key Moments - 3 Insights

Why does 'git add bigfile.psd' stage a pointer file instead of the full file?

Because Git LFS replaces the large file with a small pointer file during staging, as shown in execution_table step 3.

What happens to the large file when we push to the remote repository?

The large file is uploaded to the LFS server separately, while Git stores only the pointer, as seen in execution_table step 5.

Why do we need to add and commit the .gitattributes file?

Because .gitattributes tells Git which files to track with LFS, so it must be committed before adding large files (execution_table steps 1 and 2).

Visual Quiz - 3 Questions

Look at the execution table, what is staged when running 'git add bigfile.psd'?

A Nothing is staged

B The full large file content

C A pointer file representing the large file

D Only .gitattributes file

💡 Hint

See execution_table step 3 where staging replaces the large file with a pointer

At which step is the large file actually uploaded to the LFS server?

A Step 2

B Step 5

C Step 3

D Step 4

💡 Hint

Check execution_table step 5 where push uploads LFS objects

If we forget to commit .gitattributes before adding large files, what happens?

A Large files are added as normal files to Git

B Large files are tracked by LFS anyway

C Git throws an error

D Pointer files are created but not committed

💡 Hint

Refer to variable_tracker showing .gitattributes must be committed first to enable LFS tracking

Concept Snapshot

Git LFS tracks large files by replacing them with small pointer files in Git.
Use 'git lfs track "pattern"' to specify files.
Add and commit .gitattributes to enable tracking.
Add large files normally; Git stores pointers.
Push uploads pointers to Git and large files to LFS server.
This keeps Git repos fast and small.

Full Transcript

Git LFS helps manage large files by storing them outside the main Git repository. First, you tell Git LFS which files to track using 'git lfs track' which updates the .gitattributes file. Then you add and commit this file so Git knows to use LFS for those files. When you add a large file matching the pattern, Git LFS stages a small pointer file instead of the full file. Committing saves this pointer in Git. When you push, Git sends the pointer to the Git server and uploads the actual large file to the LFS server. This way, your Git repository stays small and fast, while large files are stored efficiently. The execution table shows each step from tracking, adding, committing, to pushing, and the variable tracker shows how files and pointers change state. Key moments clarify why pointers are staged and how the large files are uploaded separately. The quiz tests understanding of these steps.

Practice

1. What is the main purpose of Git LFS (Large File Storage)?

easy

A. To convert large files into text files for easier diffing

B. To speed up Git commit operations by compressing files

C. To automatically merge large files during conflicts

D. To store large files outside the main Git repository history

Solution

1. Step 1: Understand Git LFS functionality

   Git LFS stores large files outside the main Git history to keep the repository lightweight.

2. Step 2: Compare options with Git LFS purpose

   Options A, B, and C describe unrelated features; only To store large files outside the main Git repository history matches Git LFS's main goal.

3. Final Answer:

   To store large files outside the main Git repository history -> Option D

4. Quick Check:

   Git LFS purpose = store large files externally [OK]

Hint: Git LFS stores big files outside Git history [OK]

Common Mistakes:

• Thinking Git LFS compresses files inside Git
• Assuming Git LFS merges conflicts automatically
• Believing Git LFS converts files to text

2. Which command correctly tracks all .psd files using Git LFS?

easy

A. git track lfs *.psd

B. git lfs track "*.psd"

C. git lfs add *.psd

D. git add lfs *.psd

Solution

1. Step 1: Recall Git LFS tracking syntax

   The correct command to track files is git lfs track "pattern".

2. Step 2: Check each option's syntax

   Only git lfs track "*.psd" uses the correct command and pattern syntax. Others are invalid commands.

3. Final Answer:

   git lfs track "*.psd" -> Option B

4. Quick Check:

   Correct Git LFS track syntax = git lfs track [OK]

Hint: Use 'git lfs track "*.ext"' to track file types [OK]

Common Mistakes:

• Swapping command order like 'git track lfs'
• Using 'git lfs add' instead of 'track'
• Trying to add files directly with 'git add lfs'

3. After running git lfs track "*.mp4" and committing, what will happen when you add a new video.mp4 file and push?

medium

A. The video.mp4 file is stored in Git LFS and pushed separately

B. The video.mp4 file is pushed as a normal Git blob

C. Git will reject the push because video.mp4 is too large

D. The video.mp4 file is ignored and not pushed

Solution

1. Step 1: Understand effect of tracking and committing .gitattributes

   Tracking '*.mp4' and committing .gitattributes tells Git to use LFS for .mp4 files.

2. Step 2: Add and push a new .mp4 file

   Git LFS stores the file outside Git history and pushes it separately, so The video.mp4 file is stored in Git LFS and pushed separately is correct.

3. Final Answer:

   The video.mp4 file is stored in Git LFS and pushed separately -> Option A

4. Quick Check:

   Tracked files use LFS storage on push [OK]

Hint: Tracked files go to LFS storage on push [OK]

Common Mistakes:

• Assuming large files push normally without LFS
• Thinking Git rejects large files automatically
• Believing tracked files are ignored

4. You ran git lfs track "*.zip" but forgot to commit .gitattributes. What problem will occur?

medium

A. Git LFS will track .zip files but not push them

B. Git will refuse to add .zip files locally

C. Git LFS will not track .zip files on other clones

D. No problem; tracking works without committing .gitattributes

Solution

1. Step 1: Understand role of .gitattributes in Git LFS

   .gitattributes stores tracking rules and must be committed to share them.

2. Step 2: Effect of not committing .gitattributes

   Other clones won't know to track .zip files with LFS, so Git LFS will not track .zip files on other clones is correct.

3. Final Answer:

   Git LFS will not track .zip files on other clones -> Option C

4. Quick Check:

   Commit .gitattributes to share LFS tracking [OK]

Hint: Always commit .gitattributes after tracking files [OK]

Common Mistakes:

• Assuming local tracking affects other clones
• Thinking Git blocks adding files without .gitattributes
• Believing tracking works without committing

5. You want to track both .psd and .mp4 files with Git LFS. Which sequence correctly sets this up and shares it with your team?

hard

A. Run git lfs track "*.psd" and git lfs track "*.mp4", then commit and push .gitattributes

B. Run git lfs track "*.psd *.mp4" and push without committing

C. Add files with git add *.psd *.mp4 then run git lfs install

D. Run git lfs track "*.psd" only, then manually add .mp4 files

Solution

1. Step 1: Track each file type separately

   Git LFS requires separate track commands for each pattern, so run both track commands.

2. Step 2: Commit and push .gitattributes to share tracking

   Committing and pushing .gitattributes shares tracking rules with the team.

3. Final Answer:

   Run git lfs track "*.psd" and git lfs track "*.mp4", then commit and push .gitattributes -> Option A

4. Quick Check:

   Track each pattern + commit .gitattributes [OK]

Hint: Track each pattern separately and commit .gitattributes [OK]

Common Mistakes:

• Trying to track multiple patterns in one command incorrectly
• Forgetting to commit .gitattributes
• Running git lfs install after adding files