Git Vocabulary Every Developer Needs to Know
Commit, branch, merge, rebase, cherry-pick, stash — the 30 Git terms you will encounter in every day team communication and code reviews.
Git has its own vocabulary — and knowing these words is not just about understanding git commands. It is about understanding your team’s conversations: in pull request reviews, in standups (“I need to rebase on main”), in postmortems (“the force push overwrote the release commit”).
Here are the 30 Git terms that come up most in real team communication.
Core Concepts
Repository (repo)
The folder containing your project’s complete history. You have a local repo (on your computer) and a remote repo (on GitHub, GitLab, etc.). Phrase: “Can you push that to the remote repo?”
Commit
A saved snapshot of changes. Each commit has a unique SHA hash, a message, an author, and a timestamp. Phrase: “I’ll make a small commit after each logical change so the history is readable.”
Branch
A parallel line of development. You create a feature branch to work in isolation without affecting main. Phrase: “I’m working on a feature branch — haven’t merged yet.”
Main / Master
The primary branch of a repository. Modern repos default to main; older repos use master. Phrase: “The PR targets main — please review before merging.”
HEAD
A pointer to whatever commit you currently have checked out. Phrase: “HEAD is at commit a1b2c3d.”
Daily Workflow
Stage / Index
Before committing, you stage (or add) the changes you want to include. The staging area is also called the index. Phrase: “I’ve staged the relevant files — review with git diff --cached.”
Push / Pull
Push sends your local commits to the remote. Pull fetches remote changes and merges them locally (fetch + merge). Phrase: “Please pull before you push — there have been changes on main.”
Fetch
Downloads changes from the remote without automatically merging them into your working branch. Safer than pull when you want to inspect changes first. Phrase: “I’ll fetch and then decide whether to merge or rebase.”
Clone
Creates a full local copy of a remote repository. Phrase: “Clone the repo, then run npm install.”
Checkout
Switches to a different branch or commit. Phrase: “Checkout the feature/auth branch to test the new login flow.”
Branching & Merging
Merge
Integrates the history of one branch into another, creating a merge commit that records where the two histories joined. Phrase: “We’ll merge the feature branch after code review.”
Rebase
Replays your commits on top of another branch’s latest commit, producing a linear history. Phrase: “Rebase onto main before opening the PR — you have a conflict with the recent changes.”
Fast-forward
A merge where no merge commit is needed — the target branch pointer simply moves forward along the source branch’s commits. Phrase: “This was a clean fast-forward merge — no conflicts.”
Conflict / Merge conflict
When Git cannot automatically combine two sets of changes to the same line(s). You resolve conflicts manually. Phrase: “I got a conflict in package-lock.json — I’ll resolve it and push.”
Squash
Combines multiple commits into one. Often done before merging a feature branch to keep the history clean. Phrase: “Please squash your commits — I don’t need to see five ‘WIP’ messages.”
Advanced Operations
Stash
Temporarily saves uncommitted changes so you can switch branches without committing. Phrase: “I’ll stash my current work and check out their branch to reproduce the issue.”
Cherry-pick
Applies a specific commit from one branch onto another, without merging the entire branch. Phrase: “Cherry-pick the hotfix commit onto the release branch.”
Revert
Creates a new commit that undoes the changes of a previous commit — safe because it does not rewrite history. Phrase: “We reverted the deploy commit — that undoes the breaking change without losing the git history.”
Reset
Moves the branch pointer to a different commit, optionally clearing the staging area or working directory. Use with caution — --hard discards uncommitted work. Phrase: “I did a hard reset to get back to a clean state.”
Bisect
Uses binary search to find the commit that introduced a bug. Phrase: “I used git bisect to narrow it down to a commit from last Tuesday.”
Pull Requests & Collaboration
Pull Request (PR) / Merge Request (MR)
A proposal to merge one branch into another, used for code review. GitHub uses “Pull Request”; GitLab uses “Merge Request”. Phrase: “I’ve opened a PR — requesting review from @alice and @bob.”
Review / Approve / Request changes
Actions a reviewer takes on a PR: approve (ready to merge), request changes (must fix before merge), comment (feedback, not blocking). Phrase: “The PR has two approvals but one request for changes — address the feedback first.”
Fork
A personal copy of someone else’s repository, used in open-source contribution workflows. Phrase: “Fork the repo, make your changes, then open a PR against the original.”
Tag
A named reference to a specific commit, typically used for releases. Phrase: “We tag every release with a semantic version — e.g. v2.3.0.”
CI / Checks
Automated tests and linting that run against every PR. Phrase: “The CI checks are failing on your branch — please fix before we merge.”
Patterns & Strategies
Git Flow
A branching strategy using main, develop, feature/*, release/*, and hotfix/* branches. Common in larger teams. Phrase: “We follow Git Flow — hotfixes go directly to main and get back-merged to develop.”
Trunk-based development
A strategy where everyone commits to main (the trunk) frequently, with feature flags for incomplete features. Common in high-velocity teams. Phrase: “We do trunk-based development — no long-lived feature branches.”
Semantic versioning (semver)
A numbering scheme: MAJOR.MINOR.PATCH. Breaking changes → bump major. New features → minor. Bug fixes → patch. Phrase: “This is a breaking API change — we need to bump the major version.”
These 30 terms will carry you through 95% of Git conversations on any team. The next step: practise using them in context with our Git vocabulary exercises.