Glossary — Speak the Language

The five friends may use notebook words, but on GitHub and in job interviews people use these. This page has everything you need to talk about Git with confidence: a quick-reference table, a set of interview-ready answers (the kind of thing you can say out loud in an interview), and a Classic Interview Q&A section with the questions that come up again and again.

Quick Reference

Term	Notebook meaning	Plain meaning
Repository (repo)	The notebook + the librarian's register	A folder Git tracks, with the hidden .git directory holding all history, branches, and config
Working tree	Your desk with loose pages	The files you see and edit now — the current checkout plus any uncommitted changes
Staging area	The librarian's desk	The intermediate zone where git add puts files before git commit; lets you build commits piece by piece
Index	Another name for the librarian's desk	The technical name for the staging area; git add writes here, git commit snapshots it
Commit	A page glued into the notebook	An immutable snapshot of your files with a message, author, timestamp, and parent; identified by a SHA hash
HEAD	The name on the front of your notebook	A pointer to the commit you're currently on (normally the tip of your branch)
main	The official notebook	The default branch; conventionally the always-deployable, official version
Log	The librarian's diary	The chronological list of commits with hashes, authors, dates, and messages
Branch	A friend's own copy of the notebook	A lightweight, movable pointer to a commit — an isolated parallel line of development
Merge	Combining two notebooks page by page	Joining two lines of history; creates a merge commit unless a fast-forward is possible
Merge commit	The page where both notebooks become one	A commit with two parents, recording that two histories were combined
Fast-forward merge	Flipping the notebook to a newer page	Sliding the branch pointer forward when there's no divergence; no new commit, linear history
Rebase	Replaying your pages on top of newer ones	Re-applying your commits onto another branch's tip for a linear history; rewrites hashes
Conflict	Two friends editing the same page	Both branches changed the same lines; Git asks you to choose by editing the marked file
Detached HEAD	Standing in the past with no notebook name	HEAD pointing at a commit directly instead of a branch
Remote	The central library	Another hosted copy of the repo (usually GitHub), conventionally named origin
Clone	Copying the whole notebook	Downloading a repo with full history; sets up origin automatically
Push	Sending pages to the central library	Uploading your local commits to a remote branch
Pull	Fetching the newest pages	fetch + merge (or rebase): downloads remote commits and integrates them
Fetch	Checking what's new without taking it	Read-only download of remote commits; updates origin/* refs, changes nothing in your working tree
Upstream	The library shelf your notebook belongs to	The remote branch your local branch tracks; set with git push -u origin <branch>
origin	The main central library	The conventional default name of the remote you cloned from
Fork	A library making its own full copy of your notebook	Your personal server-side copy of someone else's repo; the basis of open-source PRs
Pull Request (PR)	A polite "please review my pages" request	A proposal to merge your branch into another, with a diff, discussion, and review
Stash	The drawer for messy work-in-progress	Temporarily saves uncommitted changes and cleans the working tree; restore with git stash pop
Amend	Rewriting the last sticky note	Replaces the most recent commit (new message or folded changes); never on pushed commits
Revert	A new entry that says "take that back"	A new commit that undoes a past commit; history stays intact — safe for pushed/shared branches
Reset	Rewinding the notebook to an old page	Moves the branch pointer back; --soft/--mixed/--hard control what happens to staging and files
Restore	Taking a page back from the desk	Discards working changes or brings a file back from a commit; doesn't move branches
Cherry-pick	Copying one page from a friend's notebook	Copies a single commit onto your current branch
Reflog	The librarian's hidden ledger of every move	Journal of every HEAD movement; how you recover commits after a bad reset
.gitignore	The scraps drawer	A file listing paths Git should never track (builds, secrets, dependencies)
Tag	A golden milestone sticky note	A permanent, never-moving name pinned to a release commit
Squash	Gluing many pages into one	Compresses several commits into a single one for a tidy history
Bisect	A guessing game to find the bad page	Binary-search through history to find the commit that introduced a bug

Interview-Ready Answers

These are written the way you'd actually say them in an interview — a definition, when to use it, and the gotcha interviewers listen for.

Core Objects & Areas

Repository (repo) A repository is a folder Git is tracking, plus the hidden .git directory that stores the entire history, branches, and configuration. It's the container for the whole project and its diary. Every Git command runs inside one. When someone says "clone the repo," they mean "copy this project with all of its history."

Working tree The working tree is the set of files you can see and edit right now — your current checkout of the project, plus any uncommitted edits. It's one snapshot in time. When you say "my changes," you usually mean working-tree changes, and git status shows which of those are modified, staged, or untracked.

Staging area / Index The staging area (also called the index) is the intermediate zone between your working tree and your repository. git add puts files there, and git commit snapshots whatever is staged. It lets you build a commit piece by piece — you decide exactly what goes in. One gotcha: git commit -a stages modified tracked files but not brand-new untracked ones.

Commit A commit is a saved snapshot of the project at a moment in time, with a message, an author, a timestamp, and a parent. It's the basic unit of Git history. Two things to remember: commits are immutable — once created they never change, you only add new ones — and each is identified by a SHA hash. Small, focused commits are what keep a history readable.

HEAD HEAD is a pointer to the commit you're currently on — normally the tip of your checked-out branch. It tells Git where new commits should attach. The classic gotcha is detached HEAD, where HEAD points at a bare commit instead of a branch. git log shows where you are; git reflog shows everywhere HEAD has ever been.

main main (formerly master) is the default branch created when you run git init. By convention it holds the always-deployable, official version of the project. Feature work happens on other branches and is merged back in. Treating main as protected — requiring review before merging — is what keeps the "official copy" trustworthy.

Log The log is the chronological diary of commits, showing hash, author, date, and message for each. git log --oneline gives a compact one-line-per-commit summary, --graph adds the branch structure, and -n limits the count. It's the first thing you look at to understand what has happened in a project.

Branching & History

Branch A branch is a lightweight, movable pointer to a commit — a parallel line of development. Creating a branch doesn't copy files; it points at the same history and moves forward as you commit. Branches make experimentation safe because your work is isolated until you merge it back. git switch -c feature creates and switches in one step.

Merge Merging joins two lines of history into one. Git finds the common ancestor, applies the changes from both sides, and creates a new commit that has both histories as parents. Merges preserve the true timeline, which is why they're safe for shared branches. If both branches changed the same lines, you get a conflict to resolve.

Merge commit A merge commit is a commit with two (or more) parents — the visible joint where two branches became one. It records both the change itself and the fact that two histories were combined. You can spot it in git log --graph as the point where two lines converge. A merge commit only appears when branches diverged; otherwise Git can fast-forward instead.

Fast-forward merge When your current branch hasn't moved since the other branch split off, Git can simply slide the pointer forward to the other branch's tip — no new commit, perfectly linear history. That's a fast-forward. Use git merge --no-ff when you deliberately want a merge commit, for example to mark where a feature officially landed.

Rebase Rebasing replays your commits on top of another branch's tip, producing a linear history as if you had branched later. It's ideal for keeping a feature branch tidy before merging. The trade-off: it rewrites commit hashes, so you never rebase commits that others have already pulled. A crisp answer: rebase for clean personal history, merge for integrating other people's work.

Conflict A merge conflict happens when two branches modify the same lines and Git can't decide which version to keep. The conflicted file contains <<<<<<<, =======, and >>>>>>> markers; you edit the file to the correct content, remove the markers, then git add and git commit. Git never silently deletes data in a conflict — it always asks you to choose.

Detached HEAD Detached HEAD means HEAD points at a commit directly instead of a branch — you're "in the past" with no branch name to return to. It happens after git checkout <hash>, and any commit you make there isn't on a branch. To fix it: git switch main to leave, or git switch -c new-branch if you want to keep the work. Nothing is lost unless you reset it away.

Sharing & Collaboration

Remote A remote is another copy of the repository hosted somewhere — usually GitHub — and by convention it's named origin. It's the central library you push to and pull from. git remote -v lists your remotes and their URLs. A project can have several remotes (your fork and the original), which is exactly what makes open-source contribution possible.

Clone git clone <url> downloads a repository with its full history into a new folder, and sets up origin plus a remote-tracking branch like origin/main automatically. It's how you get a project onto your machine for the first time. After cloning you can branch, commit, fetch, pull, and push like any local repository.

Push git push uploads your local commits to a remote branch — it's how your work leaves your machine. Two things to watch: the push is rejected (non-fast-forward) if the remote has commits you don't have yet, which you fix with git pull first; and tags don't go automatically — use git push --tags or git push origin <tag>.

Pull git pull downloads remote commits and integrates them into your current branch. It's really fetch plus merge (or rebase, with git pull --rebase). Use it to pick up teammates' changes before you push. Because it merges, it can produce conflicts, which you resolve like any other merge.

Fetch git fetch downloads remote commits into your repository without touching your working files — it only updates the remote-tracking references like origin/main. You can review with git log origin/main before deciding what to do. It's the read-only way to see what's new. A handy way to remember: fetch to look, pull to integrate.

Upstream Upstream is the remote branch your local branch tracks — the branch that plain git push and git pull talk to by default. You set it with git push -u origin feature on the first push; afterwards the commands just work. When git status says "Your branch is ahead of origin/main," it's comparing against your upstream.

origin origin is the conventional default name Git gives to the remote you cloned from. git push origin main means "push to the main branch of the origin remote." It's not special technically — just a name — but everyone uses it, so you should recognize it instantly in interviews and in code review.

Fork A fork is your personal server-side copy of someone else's repository on the hosting platform. It doesn't affect the original. You clone your fork, make changes, push to it, and open a pull request to propose merging your work into the original. Fork → clone → branch → PR is the standard open-source contribution loop.

Pull Request (PR) A pull request is a proposal to merge your branch into another branch — usually into main of a repository you don't own. It bundles the diff, a discussion thread, and automated checks, and it's where code review happens. Once approved it gets merged, often as a squash. PRs are the collaboration unit of GitHub and GitLab.

Undoing & Recovery

Stash git stash saves your uncommitted working changes and cleans the working tree so you can switch branches or handle an emergency, and git stash pop brings them back. It's the drawer for "not ready to commit, don't want to lose it." git stash list shows saved stashes and git stash save "message" names them. Stash only touches uncommitted changes, never commits.

Amend git commit --amend edits the most recent commit — changing its message or folding new staged changes into it. Because commits are immutable, amend actually creates a new commit that replaces the old one, with a new hash. The hard rule: never amend a commit that has already been pushed, or your history and your teammates' will diverge.

Revert git revert <hash> creates a new commit that undoes the changes of a past commit, leaving history intact. Because it doesn't rewrite history, it's the safe way to undo commits others might have — especially pushed ones. One detail: reverting a merge commit needs -m to specify which parent to keep.

Reset git reset <hash> moves the current branch pointer backward, "rewinding" commits. It has three modes: --soft keeps your staging area and working tree, --mixed (the default) unstages but keeps your files, and --hard discards everything. Use it only on unpushed, local commits — it rewrites history from that branch's perspective and is the risky undo.

Restore git restore brings files back — either by discarding uncommitted working changes (git restore .) or by restoring a file from a specific commit (git restore --source=<hash> <file>). It's the modern replacement for the file-level git checkout, and it never moves branches. Use --staged to unstage a file. Prefer restore for file-level undos and save reset for moving branches.

Cherry-pick git cherry-pick <hash> copies a single commit from one branch onto your current branch as a new commit with its own new hash. It's for grabbing one specific change without merging the whole branch — for example, porting a hotfix to a release branch, or pulling one commit from a teammate's unfinished branch.

Reflog The reflog is Git's journal of every time HEAD moved — resets, rebases, checkouts, everything. git reflog lists those moves with hashes. It's the recovery tool: after an accidental git reset --hard, the "lost" commits are still there in the reflog and can be checked out or cherry-picked back. If it was committed, the reflog can usually find it.

Everyday & Troubleshooting

.gitignore .gitignore is a file that lists paths Git should never track — build artifacts, node_modules/, .env files, and OS junk. Rules use glob patterns like *.log or /build/. It keeps the repository clean and prevents committing secrets or huge files. One subtlety: a file that's already tracked isn't ignored until you run git rm --cached to untrack it.

Tag A tag is a permanent name pinned to a specific commit, usually a release marker like v1.0.0. Annotated tags (git tag -a v1.0 -m "...") store a message, a tagger, and a date. Unlike branches, tags never move — they're the bookmarks for "this is exactly what we shipped." Remember to push tags explicitly with git push --tags.

Squash Squashing compresses multiple commits into one. On GitHub you can squash-merge a pull request so it lands on main as a single commit; locally you can do it with git rebase -i and marking commits as squash. The result is a clean, readable history. The trade-off is that you lose the intermediate steps, so it's best when a feature's step-by-step details aren't worth keeping.

Bisect git bisect finds the commit that introduced a bug using binary search. You mark one commit as good and one as bad, then Git checks out the midpoint; you test it, mark good or bad, and Git narrows it down until it isolates the culprit. With a large history it finds the bad commit in log₂(n) steps. Mentioning bisect when asked how you track down regressions is a strong signal.

Classic Interview Q&A

1 · What's the difference between git fetch and git pull? git fetch downloads the remote's new commits into your repository but doesn't touch your working files — you can inspect them with git log origin/main first. git pull is fetch plus merge (or rebase, with git pull --rebase): it downloads and then integrates the changes into your current branch. Use fetch when you want to review before integrating, and pull when you just want to sync up. In one line: fetch is read-only, pull changes your working tree.

2 · git merge vs git rebase — when do you use each? A merge combines two histories and preserves the true timeline, adding a merge commit — it's safe on shared branches. A rebase replays your commits on top of another branch for a clean, linear history, but it rewrites commit hashes, so you never rebase commits that have been pushed and pulled by others. My rule of thumb: rebase my own local feature commits to keep history readable, and merge when bringing in changes from other people.

3 · git revert vs git reset — how do you undo? git revert <hash> adds a new commit that undoes a past commit, keeping history intact — safe for pushed and shared branches. git reset <hash> moves the branch pointer back and removes commits from the branch's history, which is only safe for unpushed, local commits. So: revert when the history is shared and you want to preserve the story, reset when it's your own local work and you want to rewind it.

4 · How do you undo a commit that's already been pushed? You don't rewrite it — you revert it. Amending or resetting a pushed commit rewrites history and breaks everyone else's clones. Instead, run git revert <hash> to create an "undo" commit, then push that. The change is gone, the history stays intact, and every teammate stays in sync.

5 · You accidentally ran git reset --hard and lost work — how do you recover? git reset --hard doesn't wipe history immediately; the reflog records every move of HEAD. Run git reflog, find the lost commit's hash, and recover it with git checkout <hash> or git cherry-pick <hash>. As long as the work was committed at some point, it's usually recoverable. The rule: lost work → check the reflog before you panic.

6 · How do you resolve a merge conflict? A conflict means both branches changed the same lines. git status tells me which files are conflicted. I open them — they contain <<<<<<< HEAD, the ======= divider, and >>>>>>> <branch> markers — edit the content to what should stay, delete the markers, then git add the file and git commit to finish the merge. The key point is Git never deletes my work in a conflict; it just asks me to decide.

7 · What's a fast-forward merge, and what does it mean to squash? If the target branch hasn't moved since I branched off, Git can slide the pointer forward — a fast-forward merge with no extra commit and a linear history. If the branches have diverged, Git creates a merge commit that joins the two timelines. Squashing, meanwhile, compresses a whole feature branch into one commit, which keeps main tidy but loses the intermediate steps. I'd squash-merge a feature PR for a clean log, and keep merge commits when the real branching structure matters.

Remember

You don't need to memorize all of this word for word. Understand the why behind each term and the gotchas — the words will follow. Then practice every one of these in the Exercises and the Capstone, and use the Troubleshooting page when something breaks.