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.

Recommended Learning

Master Version Control

Explore the core architecture of Git, from internal object models to advanced branching and collaboration workflows.

Start Learning

GitHub Preview

user / git-essentials-lab Public
main
3 Commits
U
Initial commit foundation
a9f23e4
README.md 2 mins ago
index.html Just now
git push origin main... Total 3 (delta 1)... Compressing objects: 100%... done.
What we are building

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

  • 1
    Master the core Git workflow (Add, Commit, Push).
  • 2
    Understand branching and timeline management.
  • 3
    Collaborate 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.

Why Git?

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

  • 1
    A terminal/command prompt.
  • 2
    Git installed on your system.

Installation

First, check if you already have it. If not, download the installer for your OS.

Terminal
# Check version
git --version

# On MacOS (if missing)
brew install git

# On Windows
winget install --id Git.Git -e --source winget
Pro Tip

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.

Terminal
# 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.

Terminal
# Create a new directory
mkdir my-first-repo
cd my-first-repo

# Initialize Git
git init
The .git Folder

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".

Terminal
# Create a README file
echo "# My First Project" > README.md

# Check status
git 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.

Terminal
# Compare working directory changes against the last commit
git diff

# Compare staged changes against the last commit
git diff --staged
Why Diff?

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".

Terminal
# 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.

Terminal
# 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.

Terminal
# 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
Reset vs Revert

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.

Terminal
# 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".

Terminal
# 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
How Stash Works

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.

Terminal
# 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
Fast-Forward vs Three-Way Merge

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.

Terminal
# Switch to another feature branch
git checkout feature/login

# Rebase feature branch on top of main's latest commits
git rebase main
Merge vs Rebase

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".

Terminal
# Apply a single bugfix commit from a hotfix branch
git cherry-pick 7b3d9f2
When to Cherry-Pick?

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.

Terminal
# 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
Fork vs Clone

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.

Terminal
# Send local commits to GitHub
git push origin main

# Get changes from GitHub
git pull origin main

Final Checklist

  • 1
    Did you stage your changes?
  • 2
    Did you write a meaningful commit message?