GIT MASTERY LEARNING PROJECTS

Learn Git Mastery: From User to Git Guru

Goal: Master the usage of Git to a professional level. You will go beyond add/commit/push to understanding how to navigate complex history, rewrite mistakes, debug regressions automatically, and safely manage messy merge conflicts. You will become the person everyone calls when they “broke the repo.”

Why Git Mastery Matters

Git is the most widely used tool in software development, yet 90% of developers only use 10% of its features. When something goes wrong (detached HEAD, merge conflict, committed secrets), the average developer panics and deletes the folder to clone again.

Mastering Git means:

Fearlessness: You know that (almost) nothing is ever truly lost.
Precision: You craft clean commit history that tells a story, rather than a “wip”, “fix”, “fix again” mess.
Speed: You use bisect to find bugs in seconds that take hours to find manually.

Core Concept Analysis

1. The Mental Model: The Graph

Stop thinking of Git as a linear timeline. Think of it as a Graph of Snapshots.

      (main)
         ↓
A <─── B <─── C
              ↑
           (feature)

Commit: A snapshot of the entire project state (not just a diff).
Branch: A movable sticker (pointer) pointing to a specific commit.
HEAD: A “You Are Here” pointer attached to your current view.

2. The Three Areas (The Stage)

You must intuitively know where your changes are.

+----------------+      +----------------+      +----------------+
| Working Dir    | ---> |    Staging     | ---> |   Repository   |
| (Your Editor)  | add  |    (Index)     | commit|   (History)    |
+----------------+      +----------------+      +----------------+
        ^                       |
        |        checkout       |
        +-----------------------+

3. Movement vs. Change

Movement: checkout, switch. You move HEAD to a different commit. Files change to match that snapshot.
Change: reset. You move a Branch Pointer to a different commit. This changes history.

Concept Summary Table

Concept Cluster	What You Must Internalize
Navigation	`checkout`/`switch` moves YOU (HEAD). `reset` moves the BRANCH reference.
History Rewriting	`rebase` is copy-pasting commits to a new base. It changes commit hashes.
The Reflog	Your safety net. It records every movement of HEAD, even “lost” commits.
The Stage	You can craft commits precisely using `add -p` (patch mode).
Bisect	Binary search for bugs. The most underused superpower in Git.

Deep Dive Reading by Concept

Concept 1: The Basics & History

Concept 2: Branching & Merging

Concept 3: Tools & Debugging

Project List

These projects are designed to be “Simulation Scenarios.” You will create a repo, create a specific mess or situation, and then resolve it.

Project 1: The Precision Surgeon (Staging & Committing)

File: GIT_MASTERY_LEARNING_PROJECTS.md
Main Tool: Git CLI
Difficulty: Beginner
Knowledge Area: Git Workflow
Main Book: “Pro Git” Chapter 2

What you’ll build: A repository where you simulate “messy coding” (changing 3 different features in one file) and then use granular staging to create 3 distinct, clean atomic commits.

Why it teaches Git: Most beginners type git add . and commit everything. This teaches you the Index (Staging Area) as a tool for crafting history, not just a hurdle before committing.

Core challenges you’ll face:

Partial Staging: How to stage only lines 10-15 of a file while ignoring lines 20-30.
Atomic Commits: Ensuring that if you revert commit #2, commit #1 and #3 still work.
Diffing Staged vs Unstaged: Seeing exactly what you are about to commit vs what you are leaving behind.

Key Concepts:

Interactive Staging: git add -p (patch mode)
Diffing: git diff vs git diff --staged
Atomic Commits: The philosophy of “one logical change per commit”

Difficulty: Beginner Time estimate: Weekend Prerequisites: Basic git init, add, commit knowledge

Real World Outcome

You will have a simulated project history that looks perfect, even though your working style was chaotic.

Example Output:

# You made 3 changes in 'app.py' at the same time: a bugfix, a formatting change, and a new feature.

$ git status
Modified: app.py

# You use 'git add -p' to split them.

$ git log --oneline
a1b2c3d Feat: Add user login function
d4e5f6g Fix: Correct calculation error in total_sum
h7i8j9k Style: Fix indentation in main loop

# Instead of one "WIP updates" commit, you have 3 clean, revertible commits.

The Core Question You’re Answering

“How do I separate my messy ‘thinking process’ from the clean ‘project history’?”

Before you write any code, sit with this question. Your working directory is your messy desk. The repository history is the polished report you hand to your boss. The “Index” is where you organize the papers before stapling them.

Concepts You Must Understand First

The Staging Area (Index)
- What happens to a file when you git add it? Does it move? Or is it copied?
- Book Reference: “Pro Git” Ch. 2.2
Hunks
- What is a “hunk” in a diff?
- Book Reference: “Pro Git” Ch. 7.2 (Interactive Staging)

Questions to Guide Your Design

Scenario Setup: Create a single file with 3 distinct “logic blocks” (e.g., a math function, a string formatter, and a main loop).
The Mess: Edit ALL three blocks at once. Introduce a bug fix in one, a variable rename in another, and a new comment in the third.
The Constraint: You are NOT allowed to use git add . or git add filename. You must use git add -p.

Thinking Exercise

Trace the Staging Area:

Working Dir: Version C (Messy)
Index:       Version A (Clean)
Repo:        Version A (Clean)

When you stage the first hunk:

Working Dir: Version C (Messy)
Index:       Version B (Partial Change)
Repo:        Version A (Clean)

Draw this mental model. The Index is a snapshot builder.

The Interview Questions They’ll Ask

“What is the difference between git diff and git diff --cached (or --staged)?”
“I accidentally added a file to staging. How do I unstage it without losing my changes?”
“Why is git add . generally considered bad practice in large teams?”

Hints in Layers

Hint 1: Setup Create a Python or JS file. Commit a base version. Then open it and make 3 unrelated changes in different parts of the file.

Hint 2: The Command Run git add -p. Git will ask Stage this hunk [y,n,q,a,d,/,s,e]?.

Hint 3: Splitting Hunks If Git groups two changes into one “hunk” but you want to separate them, use the s (split) option.

Hint 4: Review Use git diff --staged to verify ONLY the bug fix is ready to commit.

Books That Will Help

Topic	Book	Chapter
Recording Changes	“Pro Git”	Ch. 2.2
Interactive Staging	“Pro Git”	Ch. 7.2

File: GIT_MASTERY_LEARNING_PROJECTS.md
Main Tool: Git CLI
Difficulty: Intermediate
Knowledge Area: Git Safety Nets
Main Book: “Pro Git” Chapter 7

What you’ll build: A repository where you intentionally “lose” work (delete a branch, hard reset a commit) and then use reflog and detached HEAD states to recover it completely.

Why it teaches Git: Fear holds users back. Once you know that Git records every commit you make (even the abandoned ones) in the reflog, you become fearless. You will also master “Detached HEAD” mode, understanding it’s just a state of “exploring without a branch label.”

Core challenges you’ll face:

Recovering a deleted branch: You deleted feature-x but realized you needed it.
Undoing a hard reset: You ran git reset --hard HEAD~1 and lost code. How to get it back?
Navigating Detached HEAD: Checking out a specific commit hash to look around without creating a branch.

Key Concepts:

The Reflog: The local journal of where HEAD has been.
HEAD vs Branch Pointers: Understanding the difference.
Object ID (SHA-1): Finding commits by hash.

Difficulty: Intermediate Time estimate: Weekend Prerequisites: Project 1

Real World Outcome

You will perform a “magic trick”: delete a branch with unique code, prove it’s gone, and then resurrect it instantly.

Example Output:

$ git branch -D valuable-feature
Deleted branch valuable-feature (was a1b2c3d).

# OH NO! I needed that!

$ git reflog
8f7e6d5 HEAD@{0}: checkout: moving from valuable-feature to main
a1b2c3d HEAD@{1}: commit: Add valuable feature code

# Resurrection
$ git branch valuable-feature a1b2c3d
$ git switch valuable-feature
# Code is back.

The Core Question You’re Answering

“If I delete a branch, where does the code go?”

It doesn’t go anywhere (immediately). The pointer (the sticky note) is destroyed, but the commit (the snapshot) remains in the database until garbage collected (usually 30 days).

Concepts You Must Understand First

Garbage Collection
- When does Git actually delete data? (git gc)
- Book Reference: “Pro Git” Ch. 10.7
Detached HEAD
- What does it mean to be “detached”? (HEAD points to Commit, not Branch Name).

Questions to Guide Your Design

Scenario: Create a repo with a linear history. Create a branch experiment. Commit something cool. Switch to main. Delete experiment.
The Panic: Simulate the realization that you deleted the wrong branch.
The Fix: Use git reflog to find the SHA-1 of the commit at the tip of experiment before deletion.

Thinking Exercise

Diagramming Reflog:

HEAD@{0}: checkout: moving from A to B
HEAD@{1}: commit: added file X
HEAD@{2}: reset: moving to HEAD~1

If you are at HEAD@{0}, how do you get back to the state at HEAD@{1}?

The Interview Questions They’ll Ask

“I did git reset --hard and lost my work. Can I get it back?” (Answer: Yes, if you committed it. No, if it was only staged/unstaged).
“What is the reflog?”
“What is a ‘detached HEAD’ state and how do I save changes I made while in it?”

Hints in Layers

Hint 1: Creating the “Loss” Commit something. Then run git reset --hard HEAD~1. Verify the file is GONE.

Hint 2: Viewing the Log git log won’t show the lost commit because it’s no longer part of the history chain reachable from HEAD. You need git reflog.

Hint 3: Recovery Once you find the hash (e.g., abc1234), you can git checkout abc1234 or git reset --hard abc1234.

Hint 4: Saving Detached HEAD If you make commits in detached HEAD, they have no branch pointing to them. To save them: git branch new-branch-name.

Books That Will Help

Topic	Book	Chapter
Reflog	“Pro Git”	Ch. 7.6
Reset Demystified	“Pro Git”	Ch. 7.7

Project 3: The History Surgeon (Interactive Rebase)

File: GIT_MASTERY_LEARNING_PROJECTS.md
Main Tool: Git CLI (Vim/Nano editor)
Difficulty: Advanced
Knowledge Area: History Rewriting
Main Book: “Pro Git” Chapter 3.6

What you’ll build: A simulated “bad history” containing typos, secrets committed by accident, and “WIP” commits. You will use git rebase -i to squash, edit, reorder, and drop commits to produce a pristine history.

Why it teaches Git: This is the difference between a junior and a senior dev. A junior pushes the mess. A senior curates the history. Interactive rebase gives you god-mode over your commit timeline.

Core challenges you’ll face:

Squashing: Combining “Fix typo” and “Update docs” into the original “Docs” commit.
Editing: Going back 5 commits to fix a typo in the code WITHOUT adding a new “fix” commit on top.
Splitting: Taking one massive commit and splitting it into two smaller ones.
Dropping: Completely removing a commit that added a simulated API key.

Key Concepts:

Rebase vs Merge: Replaying changes on top of a base.
Rewriting History: Changing SHA-1 hashes (and why you shouldn’t do this on shared branches).
The “Todo” List: The script Git generates for rebase.

Difficulty: Advanced Time estimate: 1 week Prerequisites: Projects 1 & 2

Real World Outcome

You will take a history that looks like this:

A - B - C(WIP) - D(Fix C) - E(Add Secret) - F(Remove Secret)

And transform it into:

A - B - C'(Finished Feature)

(Commit E/F are gone, C+D are combined).

Example Output:

$ git log --oneline
# Before
8d7c6a2 Remove secret key
1a2b3c4 Oops added secret key
9e8d7c6 Fix typo in function
5f4e3d2 WIP implementing function

$ git rebase -i HEAD~4
# (Magic happens in editor)

$ git log --oneline
# After
3g4h5j6 Implement function securely

The Core Question You’re Answering

“How do I fix a mistake I made 5 commits ago without adding a ‘fix’ commit on top?”

Concepts You Must Understand First

Immutability of Commits
- You can’t change a commit. You can only create a new commit that looks like the old one but with changes. This changes the SHA-1.
- Book Reference: “Pro Git” Ch. 10.2
The Rebase Script
- pick, reword, edit, squash, fixup, drop. What do they mean?
- Book Reference: “Pro Git” Ch. 7.6

Questions to Guide Your Design

Scenario: Commit a file config.txt with PASSWORD=password123.
The Mistake: Continue working, adding 3 more commits.
The Goal: Remove the password from history entirely.
Note: Merely editing the file in a new commit isn’t enough (it’s still in history!). You must drop or edit the old commit.

Thinking Exercise

Rebase Visualization: Imagine you are picking up a stack of 4 pancakes (commits). You set them aside. You fix the bottom one. Then you place the other 3 back on top. Since the bottom one changed shape, the ones on top sit differently (their hashes change).

The Interview Questions They’ll Ask

“When should you squash commits?”
“Why is it dangerous to rebase a branch that has already been pushed to a shared repository?”
“What is the difference between squash and fixup?”

Hints in Layers

Hint 1: The Command git rebase -i HEAD~n where n is how far back you want to go.

Hint 2: Removing a file from history Mark the commit as edit. When rebase pauses, git rm sensitive_file. Then git commit --amend. Then git rebase --continue.

Hint 3: Squashing Use squash (or s) on the second commit you want to merge into the first. The first one must stay pick.

Books That Will Help

Topic	Book	Chapter
Rewriting History	“Pro Git”	Ch. 7.6
Interactive Rebase	“Pro Git”	Ch. 3.6

Project 4: The Detective (Bisect & Blame)

File: GIT_MASTERY_LEARNING_PROJECTS.md
Main Tool: Git CLI + Automated Test Script
Difficulty: Intermediate
Knowledge Area: Debugging
Main Book: “Pro Git” Chapter 7.5

What you’ll build: A repository with 100 commits (generated by a script). One specific commit introduced a subtle bug (e.g., changed + to -). You will use git bisect to automate the search and find the culprit in O(log n) steps.

Why it teaches Git: git bisect is a superpower. It turns “I don’t know when this broke” into “Commit a1b2c3d broke it.”

Core challenges you’ll face:

Defining Good vs Bad: Identifying a known good state and a known bad state.
Automation: Writing a tiny script (test.sh) that returns exit code 0 (good) or 1 (bad) so Git can run the search automatically.
Blame: Once you find the commit, using git blame to see who and why.

Key Concepts:

Binary Search: How bisect works.
Exit Codes: How to tell Git if a commit is good or bad.

Difficulty: Intermediate Time estimate: Weekend Prerequisites: Basic shell scripting

Real World Outcome

You will find a needle in a haystack in seconds.

Example Output:

$ git bisect start
$ git bisect bad HEAD    # Current version is broken
$ git bisect good v1.0   # Version 1.0 worked

Bisecting: 50 revisions left to test after this (roughly 6 steps)
[a1b2c3d] Add feature X

# (Git checks out middle commit)
# You run ./test.sh or let git do it:
$ git bisect run ./test.sh

running ./test.sh
...
a1b2c3d is the first bad commit
commit a1b2c3d
Author: Evil Developer <evil@corp.com>
Date:   Mon Dec 22 12:00:00 2025

    Subtle change in calculation logic

The Core Question You’re Answering

“How do I find a bug when I have no idea where in the code it is, only that ‘it used to work’?”

Concepts You Must Understand First

Binary Search
- Why checking the middle cuts the work in half.
Shell Exit Codes
- 0 means success. Anything else means failure. Git relies on this.

Questions to Guide Your Design

Setup: Write a script to generate 100 commits. Each commit appends a number to a file.
The Bug: At commit #67, introduce a change that breaks the pattern (or simple echo "error" > status.log).
The Test: Write a check script: grep "error" status.log && exit 1 || exit 0.

Thinking Exercise

Calculate the Steps: If you have 1000 commits, how many steps does bisect take to find the bug? (Hint: 2^10 = 1024. So, roughly 10 steps. Manual searching would take avg 500 steps).

The Interview Questions They’ll Ask

“How do you find which commit introduced a regression?”
“What does git bisect run do?”
“What command shows line-by-line authorship of a file?”

Hints in Layers

Hint 1: Generation Script Use a loop in Bash/Python to commit changes. for i in {1..100}; do echo $i >> file.txt; git commit -am "Commit $i"; done.

Hint 2: Bisect Manual Start by manually running the test. git bisect good or git bisect bad. Watch Git jump around.

Hint 3: Bisect Auto Once you trust the manual process, use git bisect run <command>.

Books That Will Help

Topic	Book	Chapter
Debugging with Git	“Pro Git”	Ch. 7.5

Project 5: The Merge Conflict Dojo (Merge & Remote)

File: GIT_MASTERY_LEARNING_PROJECTS.md
Main Tool: Git CLI + Diff Tool (optional)
Difficulty: Advanced
Knowledge Area: Collaboration
Main Book: “Pro Git” Chapter 3

What you’ll build: A simulated multi-user environment (using two local folders acting as different “computers”). You will create conflicting changes, push/pull, and resolve:

Content Conflicts: Same line changed differently.
Structural Conflicts: File deleted by one, modified by another.
Diverged History: Handling git pull --rebase vs git merge.

Why it teaches Git: Conflicts are where people quit Git. You will seek them out. You will understand the <<<<HEAD markers and how the “3-way merge” algorithm thinks.

Core challenges you’ll face:

Simulating Remotes: Cloning a local folder (git clone ../remote-repo).
The “Diverged” State: Your local main is at C, origin main is at D. You can’t push. What do you do?
Resolving deletions: User A renamed file.txt to data.txt. User B edited file.txt. Git is smart enough to merge this… mostly.

Key Concepts:

Remotes: origin/main is just a pointer to “where main was last time I checked.”
3-Way Merge: Ancestor, Yours, Theirs.
Fast-Forward: When no merge commit is needed.

Difficulty: Advanced Time estimate: 1 week Prerequisites: Project 1 & 2

Real World Outcome

You will confidently fix a state where git push is rejected.

Example Output:

$ git push
! [rejected]        main -> main (fetch first)
error: failed to push some refs to ...

# The Panic Moment. But not for you.

$ git fetch
$ git log --all --graph --oneline
* a1b2c3d (origin/main) Their change
| * e4f5g6h (HEAD -> main) My change
|/
* 8i9j0k1 Common ancestor

# You choose: Merge or Rebase?
$ git rebase origin/main
Auto-merging file.txt
CONFLICT (content): Merge conflict in file.txt

# You edit the file, fix it, add it.
$ git rebase --continue
Successfully rebased and updated refs/heads/main.

$ git push
Success.

The Core Question You’re Answering

“Why can’t I push? And what are these <<<<<<< symbols in my code?”

Concepts You Must Understand First

Tracking Branches
- What is the link between local main and origin/main?
- Book Reference: “Pro Git” Ch. 3.5
Fetch vs Pull
- pull = fetch + merge (or rebase).
- Always know what your tools do.

Questions to Guide Your Design

Setup: Create a bare repo server.git. Clone it to userA and userB folders.
Conflict 1: User A changes line 1. Commit. Push. User B changes line 1. Commit. Push (fails). Pull (conflict).
Conflict 2: User A deletes file X. User B modifies file X.

Thinking Exercise

The 3-Way Merge: Ancestor: A = 1 Yours: A = 2 Theirs: A = 3 Git cannot decide.

Ancestor: A = 1 Yours: A = 1 Theirs: A = 3 Git assumes 3 is correct (change wins over no-change).

The Interview Questions They’ll Ask

“What is the difference between git merge and git rebase?”
“What is a fast-forward merge?”
“How do you abort a merge that went wrong?” (git merge --abort)

Hints in Layers

Hint 1: Local Remotes You don’t need GitHub. git clone ./my-repo ./my-repo-clone works perfectly on your local disk.

Hint 2: Viewing Conflicts git status tells you exactly which files are unmerged.

Hint 3: Rebase flow When pulling with conflicts, git pull --rebase is often cleaner than git pull (which makes a merge commit).

Books That Will Help

Topic	Book	Chapter
Basic Merging	“Pro Git”	Ch. 3.2
Distributed Workflows	“Pro Git”	Ch. 5

Summary

This learning path covers Git Mastery through 5 hands-on projects.

#	Project Name	Main Tool	Difficulty	Time Estimate
1	The Precision Surgeon	Git CLI	Beginner	Weekend
2	The Time Traveler	Git CLI	Intermediate	Weekend
3	The History Surgeon	Git CLI	Advanced	1 week
4	The Detective	Git CLI	Intermediate	Weekend
5	The Merge Conflict Dojo	Git CLI	Advanced	1 week

Recommended Learning Path

For beginners: Start with Project 1 to stop using git add . blindly. For intermediate: Jump to Project 3 to master rewriting history. For advanced: Focus on Project 5 to simulate complex team conflicts.

Expected Outcomes

After completing these projects, you will:

Never fear a detached HEAD again.
Know how to find lost code using reflog.
Be able to clean up messy history before pushing.
Debug regressions automatically with bisect.
Resolve merge conflicts without losing data.

You’ll have built a mental model of the Git Graph that allows you to predict exactly what every command will do.

Learn Git Mastery: From User to Git Guru

Why Git Mastery Matters

Core Concept Analysis

1. The Mental Model: The Graph

2. The Three Areas (The Stage)

3. Movement vs. Change

Concept Summary Table

Deep Dive Reading by Concept

Concept 1: The Basics & History

Concept 2: Branching & Merging

Concept 3: Tools & Debugging

Project List

Project 1: The Precision Surgeon (Staging & Committing)

Real World Outcome

The Core Question You’re Answering

Concepts You Must Understand First

Questions to Guide Your Design

Thinking Exercise

The Interview Questions They’ll Ask

Hints in Layers

Books That Will Help

Project 2: The Time Traveler (Navigation & Reflog)

Real World Outcome

The Core Question You’re Answering

Concepts You Must Understand First

Questions to Guide Your Design

Thinking Exercise

The Interview Questions They’ll Ask

Hints in Layers

Books That Will Help

Project 3: The History Surgeon (Interactive Rebase)

Real World Outcome

The Core Question You’re Answering

Concepts You Must Understand First

Questions to Guide Your Design

Thinking Exercise

The Interview Questions They’ll Ask

Hints in Layers

Books That Will Help

Project 4: The Detective (Bisect & Blame)

Real World Outcome

The Core Question You’re Answering

Concepts You Must Understand First

Questions to Guide Your Design

Thinking Exercise

The Interview Questions They’ll Ask

Hints in Layers

Books That Will Help

Project 5: The Merge Conflict Dojo (Merge & Remote)

Real World Outcome

The Core Question You’re Answering

Concepts You Must Understand First

Questions to Guide Your Design

Thinking Exercise

The Interview Questions They’ll Ask

Hints in Layers

Books That Will Help

Summary

Recommended Learning Path

Expected Outcomes