Advanced Git Vocabulary: English Terms for Modern Dev Workflows

Moving or replaying your commits on top of a different base commit. Rebase rewrites commit history so your changes appear after the latest upstream changes, resulting in a linear history without merge commits.

“Rebase your feature branch onto main before opening the pull request to avoid a messy merge commit.”

Running git rebase -i lets you edit, reorder, squash, fixup, or drop individual commits before sharing them. It is the standard way to clean up a messy commit history.

“Use interactive rebase to squash the five WIP commits into one clean commit before merging.”

Combining multiple commits into a single commit. Squashing is done during an interactive rebase or with the squash option in a pull request merge strategy.

“Squash all the 'fix typo' commits so the history stays readable.”

Copying a specific commit from one branch and applying it to another. You identify the commit by its SHA. Cherry-pick is commonly used to backport a bug fix to a release branch.

“Cherry-pick the security fix commit onto the 2.x release branch without merging all of main.”

Creating a new commit that undoes the changes introduced by a previous commit. Unlike reset, revert is safe for shared branches because it does not rewrite history.

“Revert the deploy commit to roll back the broken feature on the main branch.”

Moving the current branch pointer to a different commit. Soft reset keeps staged changes. Mixed reset unstages changes but keeps them in the working directory. Hard reset discards all changes.

“Use git reset --soft HEAD~1 to undo the last commit but keep your changes staged.”

Temporarily saving uncommitted changes so you can switch branches or pull updates without losing work. 'git stash' saves and cleans the working directory. 'git stash pop' restores the changes.

“Stash your changes, pull the latest commits, then pop the stash to continue working.”

A merge that simply moves the branch pointer forward because no divergent work exists. No merge commit is created. Git uses fast-forward by default when the branch can be merged this way.

“The branch was fast-forwarded because no other commits had been made to main since the branch was created.”

Occurs when two branches have made incompatible changes to the same part of a file. Git cannot resolve the conflict automatically and requires manual intervention.

“There is a merge conflict in utils.ts. Open the file, resolve the markers, then commit.”

A state where HEAD points directly to a commit instead of a branch. Any commits you make are not on any branch and can be lost when you switch branches.

“You are in detached HEAD state. Create a branch now if you want to keep your commits.”

The remote branch that a local branch tracks. When you push or pull without specifying a target, Git uses the upstream. Set with 'git push -u origin branch-name'.

“Set the upstream so you can use git push and git pull without specifying the remote every time.”

A personal copy of someone else's repository on GitHub or GitLab. Forks let you make changes without affecting the original. Pull requests go from a fork back to the original (upstream) repo.

“Fork the open-source library, fix the bug in your fork, then open a pull request to the original repo.”

A Git command that uses binary search to find which commit introduced a bug. You mark a known good commit and a known bad commit, and Git checks out the midpoint for you to test.

“Run git bisect to find which of the 200 commits between v1.4 and v1.5 introduced the regression.”

Shows which commit and author last modified each line of a file. Useful for understanding why a line exists, but not for assigning fault.

“Use git blame to see who added this conditional and when, so you can ask them about the context.”

A local log of every time HEAD moved. The reflog lets you recover commits that appear to be lost after a hard reset, branch deletion, or rebase gone wrong.

“You accidentally ran git reset --hard. Use git reflog to find the SHA of the lost commit and restore it.”

A named reference to a specific commit, typically used to mark release versions. Tags are immutable, unlike branches.

“Create a tag v2.1.0 on the release commit so it is easy to check out later.”

A tag that includes metadata: the tagger's name, email, date, and a message. Annotated tags are stored as full objects in Git and are recommended for releases.

“Use an annotated tag for releases: git tag -a v2.1.0 -m 'Release 2.1.0'.”

A script that runs automatically before each commit is created. Commonly used to run linters, formatters, or tests to prevent bad code from entering the history.

“The pre-commit hook runs ESLint and Prettier. Fix the warnings before committing.”

Git LFS replaces large files (videos, datasets, binaries) with text pointers in the repository, storing the actual files on a remote server. This keeps the repo fast to clone.

“Track PSD and MP4 files with Git LFS so the repository does not bloat over time.”

A Git feature that lets you check out only a subset of a repository's files. Useful in large monorepos where you only need to work on one package.

“Use sparse checkout to pull only the packages/api directory from the monorepo.”

A single repository that contains the code for multiple projects or packages. Monorepos make sharing code and coordinating changes easier, but require tooling (Nx, Turborepo, Bazel) to scale.

“We moved to a monorepo so the frontend and backend can share type definitions.”

A Git repository embedded inside another repository at a specific commit. Submodules let you include a dependency as source code rather than a package.

“The design system is included as a submodule. Run git submodule update --init to clone it.”

A linked working directory attached to the same repository. Worktrees let you check out multiple branches simultaneously without cloning the repo twice.

“Use git worktree to work on the hotfix branch without stashing your current feature branch.”