About the
Lab.
Welcome to the Git Essentials Lab. In this session, we'll dive deep into version control and learn how to manage code like a professional.
Master Version Control
Explore the core architecture of Git, from internal object models to advanced branching and collaboration workflows.
GitHub Preview
We'll be constructing a Version-Controlled Repository from scratch, covering staging, committing, branching, and remote synchronization. By the end of this lab, you'll have a deeper understanding of Distributed Version Control.
Lab Objectives
-
1Master the core Git workflow (Add, Commit, Push).
-
2Understand branching and timeline management.
-
3Collaborate effectively using remote repositories.
Establishing
Trust.
Git is the time machine for code. It records precisely who changed what and when, allowing you to travel back to any point in the history of your project. Let's start by getting it onto your machine.
In professional software development, you never work alone—even if you're the only coder. Git manages the complexity of changes, and sites like GitHub provide the storage and collaboration tools.
Requirements
-
1A terminal/command prompt.
-
2Git installed on your system.
Installation
First, check if you already have it. If not, download the installer for your OS.
# Check version
git --version
# On MacOS (if missing)
brew install git
# On Windows
winget install --id Git.Git -e --source winget
If you're on Windows, use Git Bash. It gives you a Linux-like terminal experience which is the industry standard for development.
Identity Signal
Git needs to know who you are so it can label your commits correctly. This is a global configuration.
# Set your display name
git config --global user.name "Your Name"
# Set your email
git config --global user.email "you@example.com"
# Verify configuration
git config --list
Project
Initialization.
Turning a normal folder into a Git repository. This creates the hidden .git folder.
# Create a new directory
mkdir my-first-repo
cd my-first-repo
# Initialize Git
git init
The .git folder contains the entire history of your project. Delete
this folder, and you lose all your commits, but your current files remain.
Writing History
Let's create something to track. In Git, files start as "untracked".
# Create a README file
echo "# My First Project" > README.md
# Check status
git status
This is the most important command in Git. Run it constantly to see which files are tracked, modified, or staged.
Viewing
Differences.
Before staging your changes, it is vital to inspect exactly what changed. The git diff command shows the precise additions and deletions in your working directory.
# Compare working directory changes against the last commit
git diff
# Compare staged changes against the last commit
git diff --staged
Running `git diff` is the developer's ultimate safety net. It allows you to verify that you aren't committing experimental debug lines, temporary console logs, or styling mistakes before you share your changes.
The Staging
Area.
Before committing, you must tell Git which changes to include. This is called "Staging".
# Stage a specific file
git add README.md
# Stage all changes
git add .
Creating Snapshots
A commit is a permanent snapshot of your staged changes. Always include a clear message.
# Commit with a message
git commit -m "initial commit: add readme"
# Verify commit history
git log --oneline
Time Travel &
Safekeeping.
Everyone makes mistakes. Git provides multiple ways to undo changes, whether they are unstaged, staged, or already committed.
# Discard unstaged changes in a file (restore it to last commit state)
git restore README.md
# Unstage a file but keep its modifications
git reset README.md
# Undo the last commit locally, keeping your changes in the working directory
git reset --soft HEAD~1
# Revert a pushed commit by creating a new commit with opposite changes
git revert a9f23e4
git reset rewrites the commit history by moving the head backwards (dangerous for shared branches). git revert creates a new commit that undoes the changes, preserving history (safe for shared branches).
Timeline Split
Branches allow you to work on new features without breaking the "Main" code.
# Create and switch to new branch
git checkout -b feature/new-design
# List all branches
git branch
Temporary Storage
What if you are in the middle of a feature, your files are half-edited, and you must switch branches immediately to fix a critical bug? You use "Stashing".
# Save your dirty working directory changes temporarily
git stash
# List all stashed changes
git stash list
# Apply the stashed changes back and remove them from the stash list
git stash pop
Stashing takes your uncommitted changes (both staged and unstaged), saves them on an internal stack, and resets your working directory to clean. Later, you can restore them using pop on any branch.
Integrating
Changes.
Once work on your feature branch is complete and tested, you merge those changes back into the main branch.
# Switch back to the main branch
git checkout main
# Merge feature branch into main
git merge feature/new-design
# Safely delete the feature branch now that it's merged
git branch -d feature/new-design
If main hasn't changed since you branched off, Git does a Fast-Forward (just moves the pointer). If main has new commits, Git creates a new Merge Commit to combine the timelines.
Rebasing
Rebasing is an alternative to merging. It moves or "replays" your branch's commits on top of the target branch, keeping the history clean and perfectly linear.
# Switch to another feature branch
git checkout feature/login
# Rebase feature branch on top of main's latest commits
git rebase main
Merge preserves the exact historical timeline but creates extra merge commits. Rebase rewrites history to create a clean, single-line timeline. Golden Rule: Never rebase commits that have been pushed to a public repository!
Cherry Picking
Sometimes you don't want to merge a whole branch—only a single, specific commit. In Git, this is called "Cherry Picking".
# Apply a single bugfix commit from a hotfix branch
git cherry-pick 7b3d9f2
This is extremely useful when a bug fix is committed to a development branch and you need to apply that exact fix to your production/stable branch immediately without bringing in other unfinished features.
The Grid.
To work on others' code, you "Fork" their repo on GitHub, then "Clone" it to your machine.
# Clone a repository
git clone https://github.com/username/project.git
# Set up upstream tracking
git remote add upstream https://github.com/original/project.git
Forking happens on the server (GitHub). Cloning brings a copy to your local workstation.
Global Sync.
Synchronize your local commits with the remote server. Push to share, Pull to update.
# Send local commits to GitHub
git push origin main
# Get changes from GitHub
git pull origin main
Final Checklist
-
1Did you stage your changes?
-
2Did you write a meaningful commit message?