Three-Tree Architecture
You are entering advanced disaster recovery training. These operations can save or destroy entire mission histories. Precision and understanding are essential for safe execution.
Commander, space missions don't always go according to plan. Equipment fails, crew members make errors, and sometimes catastrophic events require immediate intervention to save the mission. In the development universe, Git provides powerful recovery tools, but like emergency spacecraft procedures, they must be used with complete understanding and extreme caution.
You'll master Git's three-tree architecture - the fundamental system that powers all reset, checkout, and revert operations. Understanding these internal mechanisms is what separates elite space commanders from cadets who panic during emergencies.
Git uses three "trees" to manage your code:
Your actual files - what you see and edit.
Changes prepared for next commit.
Committed snapshots - the permanent history.
# git add: Working → Staging
# git commit: Staging → Repository
# git reset --soft: Move HEAD (Repository only)
# git reset --mixed: Move HEAD + reset Staging (default)
# git reset --hard: Move HEAD + reset Staging + Working (DESTRUCTIVE!)Undo commits but keep all changes staged:
# Undo last commit, keep changes staged
git reset --soft HEAD~1
# Use case: Fix commit messages, combine commitsUndo commits and unstage changes:
# Undo commits, unstage changes, keep files
git reset HEAD~2
git reset --mixed HEAD~2 # Same as above
# Unstage specific file
git reset HEAD filename
# Use case: Split commits, reorganize staging area⚠️ Destroys all uncommitted changes!
# ALWAYS create backup first!
git branch emergency-backup
# Nuclear option - destroys uncommitted work
git reset --hard HEAD~2
git reset --hard origin/main # Match remote exactly
# Use case: Discard failed experiments, recover from corruption# Switch branches
git checkout feature-branch
git checkout -b new-branch # Create and switch
# Time travel (detached HEAD)
git checkout abc123f
git checkout HEAD~5
# Restore specific files
git checkout -- filename
git checkout HEAD~3 -- filename
# Checkout vs Reset:
# - Checkout: Switch branches, restore files (doesn't rewrite history)
# - Reset: Undo commits, move branch pointer (rewrites history)Safely undo changes in shared repositories by creating new commits:
# Revert single commit
git revert abc123f
# Revert multiple commits
git revert HEAD~3..HEAD
# Revert merge commit
git revert -m 1 merge-commit-hash
# Why use revert?
# ✅ Safe for shared/public repositories
# ✅ Preserves history
# ✅ Can be reverted itself if needed
# ✅ Production-ready approachSituation: Feature branch was merged but needs to be completely undone
# Revert a range of commits
git revert HEAD~3..HEAD
# Revert merge commit (specify parent)
git revert -m 1 abc123f
# Revert multiple specific commits
git revert abc123f def456a ghi789bSituation: Entire feature merge needs to be undone
# Find merge commit
git log --oneline --graph
# Revert merge (choose main parent with -m 1)
git revert -m 1 merge-commit-hash
# Alternative: revert to before merge
git log --first-parent
git revert range-of-commitsComplete audit trail of what was changed and why it was reverted
Safe for shared repositories - doesn't rewrite history that others depend on
Can revert the revert if you change your mind later
Standard practice for fixing production issues without disrupting team workflow
Practice soft reset to fix bad commit messages:
mkdir practice && cd practice && git init
# Create messy commits
echo "file1" > file1.txt && git add . && git commit -m "stuff"
echo "file2" > file2.txt && git add . && git commit -m "more stuff"
echo "file3" > file3.txt && git add . && git commit -m "things"
# Fix with soft reset
git reset --soft HEAD~3
git commit -m "Add initial files with proper structure"
# Verify
git log --onelinegit reset --soft HEAD~1
git reset HEAD file
git checkout HEAD -- file
git reset --hard HEAD~1
git revert commit-hash
git branch backup
You've mastered Git's three-tree architecture and recovery operations.