Master Git & GitHub, properly.

Why version control?

Before you learn Git’s commands, it helps to feel the pain it removes. Every developer who has named a file report_final_v2_ACTUALLY_final.doc already understands the problem.

Software changes constantly — and rarely by one person alone. Without a system to track those changes, you hit walls fast: you overwrite a teammate’s work, you can’t tell what changed or why, you break something and can’t get back to the version that worked, and “who touched this line and when” becomes a mystery. A version control system (VCS) is the tool that records every change to your code over time, so you can review it, undo it, branch off it, and collaborate on it safely.

What a VCS gives you

Three generations of version control

Understanding how we got to Git makes its design click:

• Local VCS — early tools tracked versions only on your own machine. Fine solo, useless for teams.
• Centralized VCS (CVCS) — tools like Subversion (SVN) and CVS keep history on one central server. Everyone checks code out from it. Better for teams, but the server is a single point of failure, and you need a connection to do almost anything.
• Distributed VCS (DVCS) — Git (and Mercurial) give every developer a full copy of the entire repository, history and all. You can commit, branch, and view history completely offline, and there’s no single point of failure. This is why Git won.

Git vs GitHub — the confusion, cleared

This is the single most common beginner mix-up, and it comes up in interviews constantly. They’re related but completely different things.

Put simply: Git is the engine; GitHub is one of the garages you can park it in. You can use Git entirely on your own with no GitHub at all. And GitHub isn’t the only option — its main alternatives are GitLab and Bitbucket, which host Git repositories too and add their own features.

How Git works: architecture & internals

Most Git confusion disappears the moment you understand its three areas and what a commit really is. This is the mental model that makes every command make sense.

The three areas

Git organizes your work into three “areas.” Files move between them as you work, and the two commands you’ll use most — git add and git commit — are simply how you move changes from one area to the next.

…and git push sends committed snapshots to a remote like GitHub · git pull brings theirs back

• Working directory — the real folder of files on your disk that you edit.
• Staging area (the index) — a preview of your next commit. You git add the specific changes you want to include, which lets you craft clean, focused commits instead of dumping everything at once.
• Repository — the hidden .git directory where Git permanently stores your committed history. When you git commit, the staged snapshot is saved here forever.

What is a commit, really?

A crucial idea that surprises people: Git does not store diffs — it stores snapshots. Each commit is a complete snapshot of what all your tracked files looked like at that moment. (Under the hood Git is smart about not duplicating unchanged files, but conceptually, think snapshots, not deltas.)

Every commit is identified by a unique SHA-1 hash (a 40-character fingerprint like a1b2c3d…) computed from its contents. Change anything and the hash changes. Each commit also records its parent commit, which is how Git chains commits into a history you can walk backward through.

The object model

Internally, Git is a simple content-addressable database built from just a few object types:

So a commit points to a tree (your whole project’s folder structure), which points to blobs (file contents) and sub-trees. Everything is addressed by the hash of its content, which is what makes Git so fast and tamper-evident.

Refs and HEAD

Commit hashes are unwieldy, so Git uses friendly pointers called refs:

• A branch (like main) is just a lightweight, movable pointer to a commit. That’s the whole secret — this is why branching in Git is instant and cheap.
• HEAD is a pointer to where you are right now — usually the branch you currently have checked out. When you commit, HEAD’s branch moves forward to the new commit.
• A tag is a fixed pointer to a specific commit, typically used to mark releases like v1.0.

Terminology & glossary

The words you’ll meet everywhere in Git. Learn these and the documentation — and the interviews — read easily.

Install & first-time setup

A five-minute setup you do once per machine. Getting your identity and SSH keys right now saves headaches later.

Install Git

• Windows — download “Git for Windows” from git-scm.com; it includes Git Bash, a handy terminal.
• macOS — run git --version to trigger the developer tools install, or use Homebrew: brew install git.
• Linux — sudo apt install git (Debian/Ubuntu) or sudo dnf install git (Fedora).

Tell Git who you are

Every commit is stamped with a name and email. Set them once, globally:

git config --global user.name "Your Name"
git config --global user.email "you@example.com"

# Make "main" the default branch name for new repos
git config --global init.defaultBranch main

# Set your preferred editor (e.g. VS Code)
git config --global core.editor "code --wait"

# Check everything
git config --list

Connect to GitHub with SSH

SSH keys let you push and pull without typing a password every time. Generate a key, then add the public half to GitHub (Settings → SSH and GPG keys).

# Generate a new key
ssh-keygen -t ed25519 -C "you@example.com"

# Copy the PUBLIC key, then paste it into GitHub settings
cat ~/.ssh/id_ed25519.pub

# Test the connection
ssh -T git@github.com

The everyday workflow

Ninety percent of your Git life is one short loop: change files, stage them, commit them, push them. Master this and you’re productive.

The lifecycle of a file

Every file Git tracks moves through a few states. Knowing which state a file is in tells you what to do next:

Start a repo — two ways

# A) Turn an existing folder into a repo
git init

# B) Copy an existing repo from GitHub
git clone git@github.com:user/project.git

The core loop

git status                 # what's changed? (run this constantly)
git add index.html         # stage one file...
git add .                  # ...or everything that changed
git commit -m "Add contact form"   # save a snapshot
git push                   # send commits to the remote

Seeing what’s going on

git status                 # current state of working tree & staging
git diff                   # unstaged changes, line by line
git diff --staged          # what you're about to commit
git log --oneline --graph --all   # compact, visual history
git show HEAD              # details of the latest commit

Branching & merging

Branching is Git’s superpower. Because a branch is just a movable pointer to a commit, creating one is instant — and it changes how you work.

The idea: keep your stable code on main, and do every new feature or fix on its own branch. You can experiment freely; if it works, you merge it back; if it doesn’t, you throw the branch away and main was never touched.

# Create a branch and switch to it (modern syntax)
git switch -c feature/login
# (older equivalent: git checkout -b feature/login)

# ...do your work, add and commit as usual...

git switch main          # go back to main
git merge feature/login  # bring the feature in
git branch -d feature/login   # clean up the merged branch

Two kinds of merge

• Fast-forward merge — if main hasn’t moved since you branched, Git simply slides main‘s pointer forward to your branch’s latest commit. No merge commit, perfectly linear history.
• Three-way merge — if both branches have new commits, Git combines them and creates a new merge commit with two parents, tying the histories together.

git branch                 # list local branches
git branch -a              # include remote branches
git switch main          # switch branches
git branch -m old new       # rename a branch
git branch -D feature/x     # force-delete (even if unmerged)

Merge conflicts, demystified

Conflicts scare beginners, but they’re just Git being honest: two branches changed the same lines, and Git won’t guess which one you meant. You decide.

When a merge can’t be done automatically, Git pauses and marks the clashing spot inside the file with conflict markers:

<<<<<<< HEAD
const greeting = "Hello there!";   // your current branch's version
=======
const greeting = "Hi, welcome!";    // the incoming branch's version
>>>>>>> feature/login

How to resolve one, step by step

1. Run git status to see which files conflict.
2. Open each file and find the <<<<<<< markers.
3. Edit the file to the version you actually want — keep one side, the other, or blend them — then delete all three marker lines.
4. Stage the resolved file with git add.
5. Complete the merge with git commit (Git pre-fills a message).

git status                 # lists "both modified" files
# ...edit files, remove markers, keep what you want...
git add greeting.js        # mark it resolved
git commit                 # finish the merge

# Changed your mind mid-merge? Abort and start over:
git merge --abort

Rebasing & rewriting history

This is where Git gets powerful — and where you can hurt yourself if you skip the one golden rule. Take it slow; it’s worth it and it’s a favorite interview topic.

Merge vs rebase

Both integrate changes from one branch into another; they differ in the history they leave behind.

• Merge keeps history exactly as it happened and adds a merge commit. Honest and safe, but can get tangled with many small merges.
• Rebase re-plays your branch’s commits on top of another branch, as if you’d started from its latest commit. Result: a clean, linear history — but the commits are rewritten (they get new hashes).

git switch feature/login
git rebase main        # replay my commits on top of main
# resolve any conflicts, then: git rebase --continue

Interactive rebase — polish your commits

Interactive rebase lets you rewrite a series of your own commits before sharing them — squash several into one, reword messages, reorder, or drop them entirely.

git rebase -i HEAD~3

# An editor opens; change "pick" to:
#   squash (s) — fold this commit into the one above
#   reword (r) — keep the commit, edit its message
#   drop   (d) — delete this commit entirely
#   edit / reorder lines to reorder commits

Cherry-pick & amend

# Copy one specific commit onto your current branch
git cherry-pick a1b2c3d

# Fix the most recent commit (message or forgotten file)
git add forgotten-file.js
git commit --amend

Undoing mistakes

Everyone makes them. This is the section you’ll bookmark and return to. The key skill is knowing which undo to reach for.

Before you’ve committed

git restore file.js          # discard unstaged edits to a file
git restore --staged file.js # unstage (keep the edits)
git restore .                # discard ALL unstaged changes (careful!)
git clean -fd              # delete untracked files & folders

Fixing commits

# Fix the LAST commit's message or contents
git commit --amend

# Undo last commit, KEEP changes staged
git reset --soft HEAD~1

# Undo last commit, KEEP changes but unstage them (default)
git reset HEAD~1

# Undo last commit and THROW AWAY the changes (dangerous)
git reset --hard HEAD~1

# Safely undo a commit by making a NEW opposite commit
# (the right choice for shared/pushed history)
git revert a1b2c3d

reset vs revert — the interview classic

Remotes & collaboration

A remote is just another copy of your repo living somewhere else — usually GitHub. Three verbs keep you in sync: fetch, pull, and push.

git remote -v                          # list remotes and their URLs
git remote add origin git@github.com:you/repo.git
git push -u origin main              # push & set upstream (first time)
git fetch origin                       # see remote changes safely
git pull                               # fetch + merge into current branch

The forking workflow (open source)

You usually can’t push directly to someone else’s repo. Instead you fork it (make your own copy on GitHub), clone your fork, push changes to it, and open a pull request back to the original. Keep your fork current by adding the original as an upstream remote:

git remote add upstream git@github.com:original/repo.git
git fetch upstream
git switch main
git merge upstream/main      # pull the original's latest into your fork
git push origin main

Pull requests & code review

The pull request (PR) is the heart of collaboration on GitHub. It’s not a Git feature — it’s a GitHub one — and it’s how teams review and discuss changes before they land.

A pull request is a proposal: “here are the commits on my branch — please review them and merge them into main.” It opens a dedicated page where teammates can read the diff, comment on specific lines, request changes, approve, and watch automated checks (tests, linters) run before anything merges.

The PR lifecycle

1. Create a branch, commit your work, and push it to GitHub.
2. Open a pull request from your branch into main (GitHub usually shows a prompt).
3. Write a clear title and description — what changed and why. Link any related issue (e.g. “Closes #42”).
4. Reviewers comment, request changes, or approve. You push follow-up commits to address feedback — the PR updates automatically.
5. Once approved and checks pass, someone merges it. Delete the branch.

Three ways to merge a PR

Do it from the terminal (GitHub CLI)

gh pr create --title "Add login form" --body "Closes #42"
gh pr status          # see your PRs
gh pr checkout 123     # check out someone's PR to test it
gh pr merge 123 --squash

Issues & project management

Issues are how GitHub turns a code repository into a place to plan work, track bugs, and have conversations — no separate tool required.

An issue is a tracked item: a bug report, a feature request, a question, or a task. Each has a title, a description, a comment thread, and a set of tools to organize it:

Link issues to code

The magic connection: mention an issue number in a commit or PR and GitHub links them automatically. Use a closing keyword and merging the PR will close the issue for you.

git commit -m "Fix null crash on empty cart"
# In the PR description, write:
#   Closes #42     (also: Fixes #42, Resolves #42)
# → merging the PR auto-closes issue #42

Branching strategies

Once a team shares a repo, they need an agreed way to use branches. There’s no single “right” answer — the best strategy depends on how you ship.

Command cheat sheet

The commands worth keeping within reach, grouped by what you’re trying to do. Bookmark this section.

Real-world scenarios

The situations you’ll actually face, and exactly what to type. From your first push to untangling a mistake under pressure.

git init
git add .
git commit -m "Initial commit"
git remote add origin git@github.com:you/project.git
git push -u origin main

git switch -c feature/search
# ...work, add, commit...
git push -u origin feature/search
# open a Pull Request on GitHub, get it reviewed & merged

# after clicking "Fork" on GitHub:
git clone git@github.com:you/their-project.git
git switch -c fix/typo-in-readme
# ...make the change, commit...
git push -u origin fix/typo-in-readme
# open a PR from your fork → the original repo

# you're on main but meant to commit to a feature branch
git switch -c feature/right-place   # bring the commit with you
git switch main
git reset --hard HEAD~1            # remove it from main

git revert a1b2c3d    # makes a new commit that undoes a1b2c3d
git push

Interview questions

The Git & GitHub questions that come up again and again, with concise answers you can say out loud. Tap any question to reveal the answer.

This is a sensitive-free technical topic — but if you’re preparing for a real interview, the best follow-up is to actually run each command on a throwaway repo. Muscle memory beats memorization.