The Git Glossary Every Junior Developer Should Be Able to Explain in Interviews
Fifteen git terms organized by where they show up in real engineering work, with plain definitions and the context that makes each one stick.
Git vocabulary is one of those areas where junior developers feel either confident or completely lost, with very little middle ground.
Most developers learn git through a small set of commands they use daily (clone, pull, push, commit, merge) and pick up the rest of the vocabulary through exposure.
The exposure is uneven.
Some developers happen to encounter the harder terms early; others go years without ever needing to define “upstream” or “fast-forward” in their own words.
The unevenness becomes a problem in two specific situations: interviews and code reviews.
Interviews ask candidates to define terms that don’t come up in daily work but show up in formal evaluations. Code reviews reference vocabulary that experienced reviewers assume everyone knows.
In both cases, the developer who lacks the vocabulary loses ground that has nothing to do with their actual technical ability.
This post is a focused glossary of fifteen git terms organized by where they show up in real work. Each definition is in plain English. Each entry includes one sentence on where the term comes up and one example of usage.
The goal isn’t comprehensive git education.
The goal is conversational fluency: being able to follow technical discussions, answer interview questions, and read documentation without getting stuck on a term that should be obvious.
How this list is organized
The fifteen terms below are grouped by context, not alphabetically.
Each cluster corresponds to a specific situation where the terms tend to come up together. Reading the list in order produces a working mental model.
Skimming alphabetically would produce only definitions, which is less useful.
The clusters:
Cluster 1: terms about the local git state (what’s on your machine)
Cluster 2: terms about branches and where they’re going
Cluster 3: terms about combining work from different places
Cluster 4: terms about working with remote repositories
Cluster 5: terms about looking at history and recovering from mistakes
This grouping is what makes the glossary stick. Terms learned in context attach to a mental model. Terms learned alphabetically remain a list of disconnected words.
Cluster 1: The local git state
1. HEAD
A pointer to the commit you’re currently working from.
When you make a new commit, it gets added on top of HEAD.
The term comes up constantly in error messages and command outputs (”detached HEAD state,” “HEAD is now at...”), and developers who treat HEAD as mysterious end up confused by basic git operations.
The simplest mental model: HEAD is “where you are right now” in the project’s history.
2. Working directory (or working tree)
The actual files on your computer, including any changes you’ve made but not yet committed. Distinct from the staged area and from the git history itself.
When git status says “Changes not staged for commit,” it’s referring to changes in the working directory.
3. Staging area (or index)
The intermediate zone where changes wait to be included in the next commit. Files have to be added to the staging area (with git add) before they can be committed.
The staging area is one of git’s distinguishing features compared to simpler version control systems, and the concept comes up in interview questions about git’s design.
4. Commit
A snapshot of the staged changes at a point in time, with a message describing what changed.
Commits are the fundamental unit of git history. Each commit has a unique hash (the long alphanumeric string) and a parent (the previous commit).
The term comes up in every git conversation, but the deeper interview answer involves understanding that commits are immutable snapshots, not diffs.
Cluster 2: Branches and where they’re going
5. Branch
A named pointer to a specific commit, usually used to develop a feature or fix in isolation from the main line of work.
Branches in git are lightweight (they’re just pointers, not copies of files), which is why creating and deleting branches is fast. The lightweight nature is a difference from older version control systems and comes up in interviews about git’s design.
6. Upstream
The remote branch that your local branch is configured to track.
When you say “push to upstream,” you mean push to the remote branch your local branch is associated with.
The term comes up frequently in error messages (”Your branch is ahead of upstream by 2 commits”) and in conversations about syncing forks.
The simplest way to think about it: upstream is “where my branch came from and where it pushes to by default.”
7. Fast-forward
A merge that doesn’t create a new merge commit because the target branch’s history is a direct ancestor of the source branch. Fast-forward merges happen when nobody else has committed to the target branch since you branched off.
The term comes up in pull request descriptions and merge conversations, and understanding it is essential for following discussions about merge versus rebase strategies.
Cluster 3: Combining work
8. Merge
Combining the changes from one branch into another, usually creating a new commit (a merge commit) that has two parents. Merges preserve the history of both branches.
The term comes up constantly, but the deeper interview answer involves the difference between merging and rebasing, and when each is preferred.
9. Rebase
Reapplying commits from one branch on top of another branch, producing a linear history without merge commits. Rebase rewrites history (creates new commits with new hashes), which makes it powerful and dangerous.
The term comes up in workflow discussions, in code review feedback (”can you rebase this on main?”), and in interviews about git workflows.
10. Cherry-pick
Applying a single commit from one branch onto another, without bringing the rest of that branch’s history.
The term comes up when fixing bugs that need to be applied to multiple branches (like a fix that needs to go on both main and a release branch), and in conversations about backporting changes.
11. Conflict
A situation where two branches have changed the same lines of code in different ways, and git can’t automatically determine how to merge them.
The developer has to resolve the conflict manually by choosing which version to keep, or by combining the changes.
The term comes up constantly during merges and rebases, and confidently handling conflicts is a skill that distinguishes experienced developers from beginners.
Cluster 4: Working with remotes
12. Remote
A version of the repository hosted elsewhere, typically on a service like GitHub, GitLab, or Bitbucket.
Local repositories can have multiple remotes (commonly origin for the main remote and upstream for the original repo if working from a fork).
The term comes up constantly, but the nuance worth knowing is that remotes are just other repositories git knows about, not anything fancier than that.
13. Fork
A copy of a repository under your own account, typically used to contribute to projects you don’t have direct access to.
Forks are a feature of hosting platforms (GitHub, GitLab) rather than a core git concept, but the term comes up frequently in open-source contribution conversations.
The workflow usually involves forking the original repo, making changes in your fork, and opening a pull request back to the original.
Cluster 5: History and recovery
14. Reflog
A log of every change git has made to references (branches, HEAD) in your local repository, including changes that aren’t visible in the normal git log.
The reflog is git’s safety net: most operations that “lose” commits don’t actually delete them; they just become unreachable from any branch, and the reflog can find them again.
The term comes up most often when recovering from mistakes (”I think I deleted my work” usually means “I need to check the reflog”), and knowing it exists is one of the best forms of git insurance.
15. Detached HEAD
A state where HEAD is pointing directly to a specific commit rather than to a branch. This happens when you check out a specific commit hash instead of a branch name.
Commits made in detached HEAD state are not on any branch and can be lost if you switch branches without creating a new branch first.
The term comes up in error messages and warning prompts, and understanding it prevents the panic that the warning (”You are in detached HEAD state”) usually causes.
What’s not on this list, and why
A few git terms that didn’t make the fifteen, with brief notes on why each was excluded.
Submodules: relevant for some projects but not universally encountered. Worth learning if your codebase uses them, skippable otherwise
Squash: a useful operation but more procedural than conceptual. Knowing it exists is enough; the deeper understanding comes from using it
Annotated tags versus lightweight tags: niche enough that most developers can ignore the distinction for years without consequence
Bisect: an extremely useful tool, but more of a workflow than a concept. The Cluster 5 mention of debugging via git history covers the spirit
Stash: useful for daily work but rarely comes up in interviews. Worth learning operationally rather than conceptually
This list is not exhaustive, and any senior engineer would add or remove a few terms based on their own experience.
The fifteen above are the working baseline for junior developers in 2026, which is what matters for interview preparation and daily fluency.
How to use this list
The practical exercise: read each term and try to explain it in your own words before reading the definition.
The terms you can already explain are knowledge you have.
The terms you can’t are gaps worth closing this week.
For interview preparation specifically, the test isn’t memorizing definitions. It’s being able to construct an answer that includes the term naturally.
A strong answer to “explain rebase” includes the definition, an example of when to use it, an honest acknowledgment of when not to use it, and a comparison to merge. Constructing these answers takes practice, ideally out loud, and pays back significantly in actual interviews.
For daily fluency, the test is following team conversations without losing the thread.
If a senior says “I cherry-picked the hotfix to release-2.3,” knowing the term means understanding the entire sentence without needing to ask.
The fifteen terms above cover most conversational git, which is the right level for junior developers in 2026.
What to do this week
For developers preparing for interviews, the practical step is to write a one-paragraph explanation of each term in your own words.
Not copied from this post or anywhere else.
From scratch, as if explaining to a friend who doesn’t know git well. This takes about an hour and produces a personal reference that’s much more useful than any external glossary, because the language matches how you actually think.
For developers who want daily fluency, the practical step is to use one new term in conversation or in writing each week for the next several weeks.
The terms stick when they’re produced, not just when they’re recognized.
Using “fast-forward” naturally in a pull request description, or “cherry-pick” naturally in a Slack message, accelerates the move from passive recognition to active fluency.
Git vocabulary isn’t the hardest part of becoming a competent developer. It’s one of the most underrated parts, because the gap between knowing the terms and not knowing them is invisible from inside the developer’s head but very visible to interviewers and senior engineers.
Closing the gap is cheap and pays back disproportionately.
Fifteen terms, fluent. That’s the bar.
Lower than it looks, more useful than most junior developers realize.