Git Vocabulary Every Developer Needs to Know

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.

In Practice: Navigating Nuances for Non-Native Speakers

Let’s be honest – even experienced developers sometimes stumble over Git terminology. But for those whose first language isn’t English, the subtleties of phrasing around version control can feel particularly challenging. It’s not just about knowing what a command does; it’s understanding how to communicate effectively about it, especially when collaborating with international teams. A simple “fix” can be perceived very differently depending on how it’s framed. Consider this scenario: Sarah is reviewing a pull request submitted by David from Germany. David has implemented a new feature for handling user authentication but includes some comments in the code that are phrased rather directly – “This section needs to be more readable.” Sarah, who is learning English as a second language, might interpret this as criticism of her work, even if it’s intended as constructive feedback.

The key difference often lies in the directness of communication. In many cultures, particularly those influenced by East Asian or German traditions, expressing disagreement directly can be considered impolite. Therefore, using softer, more descriptive language is crucial when providing feedback. Instead of saying “This needs to be fixed,” a better approach would be: “Could we explore alternative formatting options for this section to improve readability and maintain consistency with the overall project style guide?” Similarly, when describing the purpose of a commit message, avoid simply stating what you did. Explain why you made those changes – “Refactored authentication logic to adhere to security best practices as outlined in the team documentation” is far more informative than “Fixed authentication.”

Another common area of confusion stems from the concept of ‘upstream’ versus ‘local.’ Understanding this distinction when communicating about merging or rebasing can avoid significant headaches. If you’re asking someone to “pull upstream,” ensure they understand you’re requesting them to update their local branch with the latest changes from the main repository, rather than simply asking them to replace their entire working copy with a new one. Clear communication is paramount when resolving conflicts or coordinating workflow across multiple branches.

Finally, remember that Git terminology itself can be complex and subtly different in its usage depending on the team’s conventions. Don’t hesitate to ask for clarification – it’s always better to err on the side of asking than making assumptions based on your understanding. The goal isn’t just technical proficiency, but also clear and respectful communication within the development process.

git checkout main  # Example: Fetching the latest updates from the remote repository.