Chapter 18: Git & GitHub

Learn version control to track changes, collaborate with others, and never lose your work again.

What is Git?

Basic Commands

Branches

GitHub

Pull Requests

Quiz

What is Git?

Git is a time machine for your code. Imagine you are writing a book and you could save a snapshot of the entire manuscript at any point. If you mess up chapter 5, you can go back to the snapshot where chapter 5 was perfect. Git lets you do exactly that with code — save snapshots, go back in time, and even work on multiple alternate versions simultaneously.

Git is a version control system (VCS). It tracks every change you make to your project files. Here is why you need it:

History — See exactly what changed, when, and by whom
Undo — Revert to any previous version if something breaks
Collaboration — Multiple people can work on the same codebase
Backup — Your code lives on GitHub in the cloud

Key Concepts

Think of Git like taking photo snapshots. Each commit is a photograph of your entire project at that moment. You can flip through your photo album (commit history) to see how your project evolved over time.

Term	What It Means	Analogy
Repository (repo)	Your project folder tracked by Git	A photo album
Commit	A saved snapshot of your changes	One photo in the album
Staging area	Changes ready to be committed	Arranging people for a group photo
Branch	A parallel version of your code	An alternate timeline
Merge	Combining two branches together	Merging two timelines

Basic Commands

These are the commands you will use every single day as a developer:

Terminal — Setting Up Git

# Configure your identity (only needed once)
git config --global user.name "Your Name"
git config --global user.email "you@example.com"

# Initialize a new Git repo in your project folder
cd my-project
git init
# Output: Initialized empty Git repository in /my-project/.git/

# Check the status of your project
git status

Terminal — The Core Workflow

# THE DAILY WORKFLOW: Edit → Stage → Commit

# 1. Check what has changed
git status
# Shows: modified files in red (unstaged) or green (staged)

# 2. Stage files (prepare them for a commit)
git add index.html          # Stage one specific file
git add src/                 # Stage an entire folder
git add .                    # Stage ALL changed files (use with caution!)

# 3. Commit the staged changes (take the snapshot)
git commit -m "Add login page with form validation"
# -m = message describing what you changed and WHY

# 4. View commit history
git log --oneline
# Output:
# a1b2c3d Add login page with form validation
# e4f5g6h Set up Express server
# i7j8k9l Initial commit

# UNDO: Discard changes in a file (before staging)
git checkout -- filename.js

# UNDO: Unstage a file (remove from staging area)
git reset HEAD filename.js

            The Git Workflow

            Working Directory  ⟶  git add  ⟶  Staging Area  ⟶  git commit  ⟶  Repository
            
            (your files)                 (ready to save)                  (saved snapshot)

Write good commit messages! Bad: "fixed stuff" or "update". Good: "Fix login form validation for empty email field". Your future self (and teammates) will thank you.

The .gitignore File

A .gitignore file tells Git which files to ignore (never track). Create it in your project root:

.gitignore — Files to Ignore

# Dependencies (reinstalled with npm install)
node_modules/

# Environment variables (contains secrets!)
.env

# Build output
dist/

# OS files
.DS_Store
Thumbs.db

Branches

Branches are like parallel universes. In one universe (branch), you are working on a new feature. In another universe (the main branch), your stable code remains untouched. When the feature is ready and tested, you merge the two universes together. If the feature turns out bad, you simply delete that universe — your main code was never affected.

Terminal — Working with Branches

# See all branches (* marks the current one)
git branch
# Output:
# * main
#   feature/login

# Create a new branch AND switch to it
git checkout -b feature/login
# Shorthand for: git branch feature/login + git checkout feature/login

# Modern alternative (Git 2.23+):
git switch -c feature/login

# Now make changes, stage, and commit on this branch
git add .
git commit -m "Add login page"

# Switch back to main
git checkout main
# Or: git switch main

# Merge the feature branch into main
git merge feature/login
# This brings all commits from feature/login into main

# Delete the branch after merging (cleanup)
git branch -d feature/login

# COMMON BRANCH NAMES:
# main (or master)    — stable production code
# develop              — integration branch
# feature/login        — a new feature
# bugfix/fix-header    — a bug fix
# hotfix/security-patch — urgent production fix

Rule of thumb: Never work directly on main. Always create a new branch for each feature or bug fix. This keeps main stable and makes it easy to review changes.

GitHub

Git runs on your local computer. GitHub is a website that hosts your Git repositories in the cloud so you can share, collaborate, and back up your code.

Terminal — Connecting to GitHub

# 1. Create a repo on GitHub (github.com → New Repository)

# 2. Connect your local repo to GitHub
git remote add origin https://github.com/yourusername/my-project.git

# 3. Push your code to GitHub
git push -u origin main
# -u = sets "origin main" as the default, so next time just type: git push

# DAILY WORKFLOW with GitHub:
# Pull latest changes from team (before starting work)
git pull origin main

# Push your changes to GitHub (after committing)
git push origin main

# Clone someone else's repo (download it)
git clone https://github.com/someone/their-project.git

# See your remote connections
git remote -v
# origin  https://github.com/yourusername/my-project.git (fetch)
# origin  https://github.com/yourusername/my-project.git (push)

Command	Direction	What It Does
`git push`	Local → GitHub	Upload your commits
`git pull`	GitHub → Local	Download latest changes
`git clone`	GitHub → Local	Download entire repo (first time)

Pull Requests

A pull request (PR) is like asking a friend to review your essay before submitting it. You write your changes on a separate branch, push it to GitHub, and then open a PR asking your team to review the code before it gets merged into main. This way, bugs get caught before they reach production.

Terminal — Pull Request Workflow

# THE PR WORKFLOW:

# 1. Create a branch for your feature
git checkout -b feature/add-search

# 2. Make changes, commit them
git add .
git commit -m "Add search functionality to task list"

# 3. Push your branch to GitHub
git push -u origin feature/add-search

# 4. Go to GitHub → your repo → you will see a prompt:
#    "feature/add-search had recent pushes — Compare & pull request"
#    Click it!

# 5. Fill in the PR form:
#    - Title: "Add search functionality to task list"
#    - Description: What you changed, why, and how to test it

# 6. Team reviews → Approves → Merge!
# 7. Delete the branch (GitHub offers a button for this)

PR Best Practices

Keep PRs small — One feature or fix per PR (easier to review)
Write clear descriptions — Explain what and why
Test before opening a PR — Make sure your code works
Respond to feedback — Push new commits to address review comments

📝 Chapter 18 Quiz

1. Which command saves a snapshot of your changes?

git add

git push

git commit

git save

2. What is the staging area?

A temporary folder on GitHub

A holding area for changes that will be included in the next commit

A backup of your repository

The main branch

3. Why should you create a new branch for each feature?

To keep main stable and isolate new work

Because Git requires it

To make the repository larger

Branches are only for teams, not solo developers

4. What should you put in a .gitignore file?

Your most important source code files

A list of team members

Git configuration settings

Files Git should not track (node_modules, .env, etc.)

5. What is the purpose of a pull request?

To download code from GitHub

To request code review before merging into main

To pull changes from another branch automatically

To delete a branch

← Chapter 17: Full Backend Project Chapter 19: Environment & Build →